protocol handling spec?

[Dave Cridland]

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 
type.


> - 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:
> /desktop/gnome/url-handlers/<protocol>/command
> /desktop/gnome/url-handlers/<protocol>/enabled
> /desktop/gnome/url-handlers/<protocol>/need_terminal
> 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 
type.)

'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.

Dave.