.desktop file: supported URL schemes key

[PCMan]

If these things never works as expected, what's the point in using
URIs in the command line?
The Exec key of the desktop entry spec allows the use of %u and %U.
If file:/// is the only scheme which really works, why bother using URIs here?
It's fine to support %f and %F, and ask everyone to use FUSE.
If we allow the use of %u and %U, than it's necessary to make sure it
can work for the purpose.
Since protocol handlers can be added to the system now, this is crucial.
If a URI scheme can be supported by two different apps, and they treat
the URI differently, this still causes bad user experience.
So URI scheme is a real issue which cannot be circumvented simply by using FUSE.

On Thu, Nov 18, 2010 at 2:58 AM, David Zeuthen <zeuthen at gmail.com> wrote:
> Hi,
>
> On Wed, Nov 17, 2010 at 9:26 AM, David Faure <faure at kde.org> wrote:
>> OK. Good for you :-)
>> Can I still request that we add the key to the .desktop files?
>> It is very much needed, for any implementation that doesn't use the FUSE
>> trick. Surely you're not saying that implementors of the desktop entry spec
>> must use FUSE absolutely?
>>
>> For instance I need to ask the VLC guys to add the information about the
>> supported protocols in their .desktop file, this would be made much easier if I
>> can ask them to add UrlSchemes=... than if I have to ask them to add X-KDE-
>> Protocols=...
>>
>> So, can I add UrlSchemes to the spec? You're free to ignore it in GIO :)
>
> Actually, sorry, but I'm still opposed to adding this to a
> freedesktop.org specification. Here's why: The problem is that it will
> never really work properly because *unless* you use the same code in
> both applications, e.g.
>
>  1. the interpretation of the given URL is the same in both apps
>  2. both apps have access to the same pass-phrases / cookies
>  3. the end points actually support more than one initiator
>    (e.g. more than one login for e.g. network shares)
>
> In reality, we found over the last ten years in GNOME that this never
> is the case and we found that things never really worked. Unless, of
> course, both apps are using *exactly* the same code.
>
> Heck, for example, the GVfs interpretation of ftp:// greatly differs
> from that in e.g. your Web Browser. And smb:// usually requires
> login/passwords. So the user gets to enter his password once in, say,
> the file manager (when setting up the share) and then again (in a
> different looking dialog!) when using the app (e.g. VLC or mplayer).
> That's just a really bad experience.
>
> Further, for password hygiene you don't want your dot-files in $HOME
> littered with passwords for all your different apps. Further, you
> don't want randomly written password dialog code of dubious quality
> (e.g. not zeroing memory) to run - instead, ideally, you want to
> request the password via a *secure* and *trusted* path so even the
> requesting app cannot steal the password [1].
>
> On the other hand, these problems don't exist when using FUSE. For
> example, it would make GIO apps work (and all other apps too) a lot
> better when launched under KDE since they would be able to reuse the
> same connection and thus not re-prompting the user for passwords. It's
> just 1000 times easier. So I'm not sure why you are so adamant about
> not using FUSE in KDE - I mean, if you don't you're signing the user
> up for these problems.
>
> So, based on this, I'm against adding UrlSchemes to the spec since it
> will lure people into believing that exchanging URLs between *wildly*
> different apps works. While the reality is that it really won't work
> at all.
>
> (btw, feel free to exchange "use same code" above with "implement
> exactly the same behavior (e.g. URL scheme semantics), use same file
> formats, locking, password store and so on. Which, to just cover the
> mainstream protocols, would be hundreds of pages of fd.o specs, lots
> of conformance tests, etc. etc. Sorry, but it's totally unrealistic we
> can do that here in the freedesktop.org project.)
>
> Thanks,
> David
>
> [1] : GIO is designed to support a trusted path for password entry - see
>
> http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html
>
> and surrounding messages. We might even implement for GNOME 3 since
> all password dialogs will be system modal (so they look more like the
> OS and less like each app) and probably run in the shell process
> (which we can put in a different security context or something so
> normal apps can't get the passwords out via e.g. ptrace())
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>