Re: .desktop file: supported URL schemes key
On Wednesday, November 17, 2010 13:58:28 David Zeuthen wrote: 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. Um, I thought the whole purpose behind URLs is that they are supposed to be a uniform way to locate a resource. This *should* mean that they work in different applications, even wildly different ones. I will grant your point that having a dedicated, trusted, secure application for handling password management is much better than having it across different applications. But that's a very lame reason for disabling the other 99.9% (or so) of URL uses. As in David's example of VLC, how often is it that opening up an http:// or ftp:// URL should require authentication? I can't speak for others in KDE but just as a general principle I wouldn't say we're opposed to FUSE per se, but opposed to making it a required dependency for network I/O to work at all between different applications. I don't know that GNOME is targeting any other desktops for example, but does GNOME VFS really not work at all on Windows or OpenBSD? (Two OSes that from what little I can tell have no FUSE support). KIO already handles the issue of authentication for instance, so it's not like we have to worry about applications stealing passwords that way (I make no claims as to how many security best practices are used in that handling -- but that is orthogonal to this discussion). Obviously that doesn't matter when launching Evince from Dolphin or Kaffeine from Nautilus... but it's still orthogonal to this discussion. I actually rather like the idea of centralizing authentication concerns (as in some kind of auth-agent similar to ssh-agent or gpg-agent) but I'm really not seeing how that's relevant to UrlSchemes in the Desktop Entry spec. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file: supported URL schemes key
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, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file: supported URL schemes key
On Sunday 07 November 2010, David Zeuthen wrote: Hi, The GIO/GVfs behavior is described here: http://library.gnome.org/devel/gio/unstable/GAppInfo.html#GAppInfo.descrip tion As you can see, GIO apps never ever pass URIs to apps if the URI is available via a FUSE mount (virtually all interesting protocols such as smb, sftp, ftp and so forth). Second, GIO apps will map things back (thus avoiding FUSE). Third, at the same time non-GIO apps, such as mplayer or VLC, works just fine (through FUSE). Therefore, we actually don't have the problem in GNOME that you are trying to solve. 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 :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file: supported URL schemes key
Hi, On Wed, Nov 17, 2010 at 9:26 AM, David Faure fa...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file: supported URL schemes key
Hi, The GIO/GVfs behavior is described here: http://library.gnome.org/devel/gio/unstable/GAppInfo.html#GAppInfo.description As you can see, GIO apps never ever pass URIs to apps if the URI is available via a FUSE mount (virtually all interesting protocols such as smb, sftp, ftp and so forth). Second, GIO apps will map things back (thus avoiding FUSE). Third, at the same time non-GIO apps, such as mplayer or VLC, works just fine (through FUSE). Therefore, we actually don't have the problem in GNOME that you are trying to solve. Thanks, David ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file: supported URL schemes key
On Mon, 2010-10-11 at 13:08 +0200, David Faure wrote: The recent discussion raises again something that has been a need for a very long time. Some programs support URLs (Exec=foo %u) but not all URLs. For instance VLC supports http, ftp, and smb. We need to know that we can pass it such URLs, and not others. I would like to propose a key UrlSchemes in the desktop entry standard, as a ;-separated list of supported URL schemes. For instance, for vlc: UrlSchemes=http;ftp;smb; This problem pretty much doesn't exists in GNOME, as: - either a local FUSE URI will be passed to the program (eg. opening smb://myserver/myshare/foobar.txt will actually pass the URI version of ~/.gvfs/myshare on my server/foobar.txt) - or the supported schemes are listed using the x-schema-handler/ stuff This means that you would only have problems when launching GNOME apps under KDE, but not when running in GNOME, XFCE, LXDE (which use gvfs). Again, that's probably only a problem if KDE didn't get FUSE support for KIO since the last time I looked at it. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: .desktop file: supported URL schemes key
On Friday 05 November 2010, Bastien Nocera wrote: On Mon, 2010-10-11 at 13:08 +0200, David Faure wrote: The recent discussion raises again something that has been a need for a very long time. Some programs support URLs (Exec=foo %u) but not all URLs. For instance VLC supports http, ftp, and smb. We need to know that we can pass it such URLs, and not others. I would like to propose a key UrlSchemes in the desktop entry standard, as a ;-separated list of supported URL schemes. For instance, for vlc: UrlSchemes=http;ftp;smb; This problem pretty much doesn't exists in GNOME, as: - either a local FUSE URI will be passed to the program (eg. opening smb://myserver/myshare/foobar.txt will actually pass the URI version of ~/.gvfs/myshare on my server/foobar.txt) 1) this means you pass a FUSE URI to all programs no matter what, never the real URI? Otherwise, how can you find out if you should do one or the other? E.g. if you sometimes pass URI (to gnome programs), how do you not pass unsupported-URIs to KDE programs? I think the solution you described is for the case where no %u is present. But how would you handle a KDE program, which comes with %u but doesn't support ssh:// (assuming that's a valid gnome scheme; in kde it's called fish or sftp)? This is exactly why we need a UrlSchemes key. 2) I have strong objections against FUSE, what happens if the server goes offline, won't the mount hang like NFS mounts do in such a situation? But we probably should not get into technical discussions on a list which is supposed to be about common standards instead :-) = Let's use different fallback solutions when the URL scheme is not supported, if we decide to, but for this we first need to come up with a way to -know- that a given URL scheme is unsupported by a given application. This means that you would only have problems when launching GNOME apps under KDE [...] ... or OpenOffice, or anything else, yes. Under KDE and under any other environment that doesn't use FUSE. Like any platform where FUSE is not available, for instance. And the problem exists when launching KDE apps under GNOME, too, if I'm right about 1) above. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
