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