protocol handling spec?
dave at cridland.net
Mon Aug 9 11:25:09 EEST 2004
On Sat Aug 7 12:30:52 2004, Christian Neumair wrote:
> While we've made much progress in desktop environment-independent
> handling of MIME types, that's not the case for protocol handling.
> I don't know all of the requirements yet, so here are some basic
> question that come in mind when talking about protocol handlers:
> - protocol://path/file.doc != protocol://path/file.xls?,
> i.e. should protocol handling have any relation to MIME handling?
It's "scheme". But besides that bit of pedantry, I think it's pretty
obvious that the answer must be yes. The real question is where -
until the URI is resolved to some degree, we can't know the media
> - good idea to integrate with application .desktop files?
> - how to deal with multiple handlers?
I think both the above are deferable until we know a bit more.
> - current intermediate solution in GNOME: gconf has:
> What about KDE?
And Rox, too, and several others.
Prior art in this area is huge - Mosaic did it, for one thing, prior
to almost all of us even being aware the internet existed, and almost
certainly prior to all of us being aware that URIs existed.
> - only deal with remote files? What about file://?
'file' scheme URIs can be local or remote - the protocol used for
remote file access is left unspecified.
Some schemes with 'special' cases:
'mailto' - usually referred to as the bad example of a URI scheme,
because it's not one - it doesn't refer to a resource, but tells you
to compose an email message. However, it's also trivial to handle -
just fire up the composer application (or general email app), and
away you go.
'http' - You'd think this one would be simple, but it's also heavily
overloaded. A URI like this might indicate a web page, a DAV folder,
or a Subversion repository. Which we want to do largely depends on
the context of the link, as well as remote capabilities. Oh, and if
we get an error finding the file, the error message itself might have
useful content, and we need to display that to the user.
'imap' - Particularly fun. An imap URI may point to an IMAP mail
folder, or might point to a mail message (which has a media type,
after all), or a particular attachment (which has a useful media
'acap' - I'll include this as a counter-example, really. An ACAP URI
might be referencing bookmark data or addressbook data or something
else, and it's very difficult to know what to do with the URI - you'd
have to ask the user - but it's easy to know which application to
hand the URI to, because the class of the data is encoded in the URI.
'data' is an easy one, since everything you need - including the data
- is present.
I think a lot of the problem with trying to unify this sensibly is
that *all* schemes are, essentially, special cases. If a system could
handle 'http' and 'imap' sensibly, though, it would probably be able
to cope with the lot.
More information about the xdg