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 [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
