<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 30, 2016 at 5:11 PM, Alberto Ruiz <span dir="ltr"><<a href="mailto:aruiz@gnome.org" target="_blank">aruiz@gnome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">How are people going to get these files most of the time? A web browser? In that case the name itself is really not that important as the MIME icon used in the file browser would give them a hint and at the end of the day the browser will just open GNOME Software in both cases, right? I think that the extension should not be considered UI but an implementation detail for developers and system operators.<br></div></blockquote><div><br></div><div>The strongest argument I've seen for not making this change is that in many cases users simply won't be exposed to the file extension: on GNOME, for example, if you download from a website and select the default action, the file will be opened directly in the Software app and the user will never see it.<br><br></div><div>There will be cases where this doesn't happen. Users have the option to save the file to their downloads folder, which they might choose to do for various reasons. You might have cases where users want to pass apps around on a USB stick or similar. One question, I suppose, is the degree to which we care about these other cases.<br><br></div><div>I agree that we shouldn't rely on the file extension in order to communicate information to users. That said, I do think that, when users are exposed to information, we should seek to ensure that it doesn't confuse or place a cognitive burden. In this regard the issues with what we currently have are:<br><br></div><div> 1. The word "flatpak" won't be recognised (although, the more I think about this, maybe that's OK - perhaps users will be happy to gloss over the fact that there's a word they don't recognise).<br></div><div> 2. The file endings concatenate several words, as in "flatpakrepo" and "flatpakref", which makes the words themselves hard to distinguish<br></div><div> 3. The "ref" in flatpakref is particularly obscure; I think this is one of the main issues for met<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>If even then we want something more explanatory appsrc and applink might do it, three letter extensions are a thing of the past and not that unusual these days to find longer extensions (i.e. .torrent).</div><br></blockquote><div><br></div><div>There's certainly no need for us to specifically restrict ourselves to a three letter acronym. .torrent is a really good example - it has never seemed problematic to me. I think the reasons for that are:<br><br></div><div>1. It's simple - a single word<br></div><div>2. The idea of a "torrent" is recognised by anyone using torrents - the name is generally already familiar<br><br></div><div>The fact that appsrc and applink contain "app" makes them much more intelligible than "flatpak". However, I'm not so sure about the "src" and "link" part. There's an implied meaning there that won't be obvious to many, and could therefore cause confusion.<br><br>This makes me return to the question of why we can't use simple file endings like .app (.flatpak) .install (.flatpakref) and .repo (.flatpakrepo). Is it really not possible to use those?<br></div><br></div><div class="gmail_quote">Allan<br></div></div></div>