.desktop file: supported URL schemes key

[David Faure]

On Wednesday 24 November 2010, PCMan wrote:
> 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.

Yes exactly.
What GIO is doing is to "not use the %u feature at all". Well, that's fine.
My request is for improving the %u feature, for those actually using it, by 
adding the information about the supported schemes.

David Zeuthen wrote:
>  1. the interpretation of the given URL is the same in both apps

Seems to work for the most common ones, http, ftp, smb...
smb is the one triggering all this: OOo supports smb, VLC doesn't, we can't 
guess that from the .desktop files unless there's a urischemes entry.

>  2. both apps have access to the same pass-phrases / cookies

Cookies are pretty HTTP specific, and HTTP doesn't work like a filesystem, so I 
assumed FUSE didn't work for HTTP anyway and that you would pass real urls for 
http?

Sharing passwords: well, that's what the "secret service" guys are working on
(the kwallet and gnome-keyring guys, AFAIK). And surely the user would rather 
type a password twice than get the current behavior of passing unsupported 
urls to OOo or downloading to local file before opening vlc.

>  3. the end points actually support more than one initiator
>     (e.g. more than one login for e.g. network shares)

Yes, this can break if using different implementations and if there's a 
connection limit.

But FUSE isn't a magic bullet either. It will lead to completely hanging I/O 
when the remote host goes down (or you lose network connection, etc), just 
like NFS mounts, I presume. And it is obviously not a fully portable 
solution... I see that linux/bsd/mac should work, but the link to "fuse on 
Windows" from http://en.wikipedia.org/wiki/Filesystem_in_Userspace is just a 
broken link, and I doubt it works on Windows? Surely it doesn't work on 
Solaris either, etc. Or on some more limited mobile platforms.
More generally I don't see how we can make "application A starts application B 
in order to display uri U" dependent on a non-standard OS-level feature 
(mounting remote paths as a filesystem), one which seems fragile because it 
means using synchronous I/O for accessing remote directories, something which 
never works right -- blocks your application if the I/O is done in the main 
thread, and can even make it hang for a very very long time if the network 
communication fails.

But I'm not trying to convince you against using FUSE, I'm merely trying to 
point out that FUSE isn't the magic bullet that solves the universal problem 
of starting another application to display a remote document, and that for %u 
to make sense in the desktop entry standard, a UriSchemes key is needed.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).