protocol handling spec?

[Dave Cridland]

On Thu Aug 12 00:35:21 2004, Avery Pennarun wrote:
> Now, is MIME-type inode/blockdevice a good idea or a hack?  I think 
> it's a
> hack, because /dev/dsp *actually* contains audio/basic, and I have 
> a MIME
> viewer for that, and it might make some kind of sense to start that 
> when I
> click on /dev/dsp.  But I really don't know what to do in this 
> case.  I
> think we're pretty safe to ignore this particular one, since people 
> don't
> *actually* navigate into /dev in konqueror or nautilus and try to 
> launch
> block devices.

Yes, absolutely agree on all counts - /dev/ is an edge case, of 
course. It's an interesting one, though, and I'm a big believer that 
if you can find some edge cases and still have them handled in a sane 
manner, then this is a very useful thing indeed.

Now note that I'm not arguing that we *should* support devices in 
dev, but I do think it's worth examining how they *might* be 
supported, to see if there's anything we can reasonably learn.

I don't think there's ever an application you'd want to start by 
default for many of the items in /dev/, but there are actions it'd be 
reasonable to offer for some of them. The thing is, in this case the 
resource itself has been completely ignored, and the MIME type is 
purely derived from the filename, without reference to the actual 
resource the URI is referencing. In other words, we've broken our 
model.

In this case, we know some interesting things - we know that 
/dev/dsp, for instance, doesn't 'contain' audio, as such - it's not 
as if it's a file which happens to contain an audio file containing 
precisely what you're about to say into the microphone. It behaves 
like one in certain respects, though, and 'dereferencing' the URI 
does indeed produce an audio stream.

But you wouldn't want to blindly open it - you want to know it's not 
just any old audio resource.

So while it has a 'file' scheme URI, and the resource definitely has 
a MIME type of 'audio/basic', that's where the similarity with a 
normal audio file stops. (I'm taking it as read it is audio/basic, 
and moreover that reading from it is listening to the microphone 
input. I don't know anything about /dev/dsp and sound in general, 
though.)

I'm not entirely sure how to deal with this in any way that is useful 
elsewhere. One thing that strikes me as a possible solution is to 
mark the resource as different - the problem is, it is and it isn't. 
Maybe this is another example of some magic 'usage' name, which 
indicates that this isn't an ordinary file scheme URI pointing at a 
audio/basic resource, but you don't like that idea. (Yet, I'm hoping 
to convince you.)

> > The way I see it, some URIs are streamable, some are not. Some 
> can be > coerced into behaving like a stream, some cannot at all.
> 
> The ones that cannot be coerced into a stream cannot be "viewed" by
> konqueror.  Thus the URI handler for those types should launch an 
> app
> instead.  This is what I've been saying all along.
> 
> 
Yes, but moreover, this shouldn't ever be done as a side-effect of 
trying to get a stream.

Perhaps I'm just really scared of side-effects. Perhaps I'm just 
recalling the Security Considerations section of (almost) every URI 
RFC.


> > I think it's a mixture. It's a readable stream interface, if > 
> available, and apparently what the user wants. It's treating it as 
> a > URI container, if available, and if we think that's what the 
> user > wants. Finally, it's running some other program to handle it 
> if we > think that's what the user wants.
> 
> Agreed.
> 
> 
This, incidentally, is where the problem about user context comes in, 
since it's reasonable to try to treat 'http' scheme URIs in all the 
above ways. But you have to probe them in order to do so, and that's 
a side-effect.

> > It depends on what the user's trying to do. If they tried 
> treating > that URI as a file, it's reasonable to say "Sorry, but 
> an IMAP server > isn't a file." Or EISDIR, if we were mad enough to 
> get this working > on the command line.
> 
> Also fine with me.  This is far less hacky than http's approach of 
> rendering
> directories as HTML documents if they have no index.html.
> 
> 
Well, that's not HTTP's approach, rather the convention of web 
browsers. HTTP offers nothing to do with directories, all URIs it 
handles in its base specification are all either streamable resources 
or errors. (Errors are, of course, not only human-readable streams, 
but also often have useful information and sometimes useful features. 
See, for instance, http://www.virginradio.co.uk/cridland by way of a 
typical example which happens to show you information about my 
brother.)

This of course results in DAV folders which you can look at as if 
they were a webpage. Ultimately, it'll result in everything being 
viewable as a web page, thanks to the apparent belief of many 
otherwise sensible people who believe that everything should travel 
on port 80.

> > >That's nice.  But I'm not sure I would ever want to send my 
> iCalendar
> > >object to a different program depending on the MIME parameters.  
> Maybe
> > >I'm wrong.
> > > For iCalendar, probably not. For text/directory, you almost 
> certainly > do.
> 
> I don't follow.  What parameters does text/directory take?  Which 
> different
> programs would I want to send my text/directory object to, 
> depending on
> those parameters?
> 
> 
Ah, right.

text/directory; profile=vcard

The above is the MIME Type for vCard 3.0. Of course, everyone's using 
vCard 2.1, which is usually denoted as the non-standard text/x-vcard, 
and isn't quite interoperable, and because Windows can't handle 
dispatch of MIME Types by parameters either, then Outlook has stuck 
with 2.1, trapping the world in a Redmond-induced timewarp. Shame, as 
2.1 happens to be the ugliest format I know of.

But aside from that, there are potentially other text/directory 
possibilities. None, I *think*, are defined as yet, but if one were, 
you vCard-handling-app might get mighty confused. (Except, of course, 
your vCard handler only supports 2.1, most likely.)

In the case of iCalendar, it might be nice to show an invitation with 
a different icon to an established calendar entry. Certainly it's 
different to a request for free busy information.

> > >Okay then.  Well, I think we can agree that *most* people, when 
> they see
> > >an http: url, expect it to be treated as a web page.  So for 
> URIs that
> > >expect to be treated as something else, we can use another handy 
> feature
> > >of monikers: nesting.
> > >
> > >	svn:http://foo/blah
> >
> > Sorry, not a URI anymore. Therefore I can't copy that, chuck it 
> into > an email, and except someone else to be able to do anything 
> with it. > (In fact, Subversion uses svn: for something else 
> anyway.)
> > > Moreover, that means I can't copy that to my web browser, 
> should I > want to. (I quite often do with Subversion URIs, it's a 
> convenient > pager interface to see what's in the repository.)
> 
> It's not a URI, but it is a moniker, and if I paste it into my web 
> browser
> and my web browser knows that all svn: (we can call it something 
> else)
> monikers must be passed to the Subversion app for processing however
> Subversion wants to process things, it'll be great.
> 
> 
No, in fact, I'll bet you a million that my web browser *can't* 
handle that, and *doesn't* know. That's a foolish bet to take, of 
course. I'll also bet that not all web browsers capable of running on 
Linux will ever handle that. Nor will subversion. Moreover, if I 
paste a URI into my web-browser, that's because I want to treat it as 
a web page, anyway.

Consistency is, I think, an important goal here.


> Can you email it to people?  Well, if we standardized the 
> processing of the
> svn: (let's rename it) moniker, then yes.  If we don't, then you 
> can't, but
> you can't really email them http://foo/blah either, unless you also 
> tell
> them *to paste that URI directly into subversion*.
> 
> 
No, we cannot standardize anything outside our remit, which is 'free' 
desktops.

We cannot possibly standardize that Windows should follow our lead, 
for instance. To do so would require IETF support (which is unlikely 
on the face of it for that proposal, since it breaks backwards 
compatibility), and moreover it would require the likes of Microsoft 
to support it.

I'm afraid we're stuck with the vagueness of what an http URI means.

An 'http' scheme URI I can email to people. I can tell them to use a 
Subversion client to open it. That's okay. It'd be *nice* if I could 
email a multipart/alternative with a Desktop file that said "Use a 
subversion client, failing that a DAV client" somewhere, plus a 
Microsoft-style URL shortcut file, plus a text/uri-list, plus a 
text/html and text/plain with human-readable directions. But I'm not 
desperate for that.

Aside: Subversion's http URIs are a superset of DAV. Subversion's 
file URIs don't resolve to a real file, which is annoying, but also 
non-standard, hence a SEP.


> Essentially, in this case subversion requests a different interface 
> from the
> monikers it's given than a web browser might.  Which interface you 
> want to
> request is not intrinsically a feature of the URI (I suppose this 
> is the
> point you've been making all along).  It is, however, a feature of 
> the
> application you're in, and if we're talking about standardizing the 
> location
> of URI handlers across desktops, I think the application we're 
> mostly
> talking about is the file/web browser (which is the point I've been 
> trying
> to make all along).
> 
> 
No, there's anything using the VFS stuff.

And subversion doesn't support our standard. Nor does Lynx, nor does 
Mozilla. I very much doubt they ever will. GNOME has at least two 
different webbrowsers, and I still find it fascinating that many 
people appear to prefer to use Mozilla even so. I know of many people 
who use Lynx for most web browsing, as well.

If we're dealing with URIs, we need to deal with URIs. Treat them as 
monikers as much as you like, and it's probably a useful method, but 
they have to remain URIs.


> So can we agree that:
> 
>  - we don't need to standardize URI handlers for Subversion, 
> because it's
>    application-specific.
> 
> 
Kind of. There's little point in having a cunning API to allow you to 
treat an 'http' scheme URI to a subversion repository as a stream, 
because it *is* an 'http' scheme URI - the standard handling for 
'http' will cope with that just fine.

However, if I drag said URI out of my Subversion client, drop it onto 
the desktop, and later launch that URI-shortcut-thing, then I think 
it's perfectly reasonable to expect it to open in my Subversion 
client.

I hereby curse the cult of port 80 for this mess, of course.

We can do this by storing an extra thing in with the URI shortcut 
file thingy, of course. Lack of the thingy might mean 'use the 
default', which is always possible anyway. (And if not, it has to be 
because another app isn't following the standard, and is hence a SEP)

For desktop files, we could say "Handler=" plus a buch of handler 
'types' that we additionally want to use. This'd be doubly nice, 
because we could phase out all the myriad of invented, non-standard, 
schemes which get used by the likes of Nautilus. (Like 'start-here' 
URIs, purely there as a reinterpret_cast<nail>. It could say 
file://localhost/[...] "But use a menu handler for preference.")

Freedesktop.org could host a registry for handler types, which we 
could use URNs for, or something similar. (So, for instance, a 
subversion desktop link might have a Handler looking like 
"urn:xdg:uri-handlers:subversion,urn:xdg:uri-handlers:dav", the 
additional 'normal webbrowser' being always silently present.)

I agree that this makes it more complex than simply taking a URI and 
using it as a moniker. Feel free to curse the cult of port 80 along 
with me.

Perhaps what we really need is a moniker, or set of them, which 
provides an interface which we can throw URIs at - in other words, 
the urn:xdg:uri-handlers:* are the monikers, and the URIs are not. 
Again, an implementation detail. We'd also need a method for getting 
the default URI handler for a given URI, on the assumption we aren't 
always told what to use.


>  - standardizing URI handlers (and their APIs) across konqueror, 
> nautilus,
>    and mozilla would be nice.
> 
> 
I doubt we'll be able to persuade Mozilla into handling this stuff. 
Not for a long while yet, at any rate. We have to co-exist with 
applications that don't understand whatever standard we come up with, 
anyway.


>  - even URIs that can't reasonably be converted to a bitstream 
> should be
>    able to implement the standard URI handling API, even if 
> creating the URI
>    handler simply launches some other app and tells you (konqueror,
>    nautilus, etc) to go away.
>    

Or tells you that's the only way to handle it, and lets you make a 
decision based on that. As I say, I'm a great believer in avoiding 
side-effects.


>  - URIs that *can* be converted to bitstream give a MIME type to 
> that
>    bitstream, and the MIME type determines the application that 
> should be
>    used to view/edit/print/etc that URI.  Plus, since the object is 
> not
>    always ideally represented as a bitstream, we should give the 
> MIME app
>    our URI handler object, not the bitstream itself (if the MIME 
> app can
>    handle it), and not just the URI string (since we may have 
> already had to
>    retrieve it once, and we'd rather not do it again).
>    

If you're intent on dispatching via MIME type, which has always 
struck me as a reinterpret_cast<nail> sort of solution anyway, then 
that's very much an implementation detail at best, and probably not 
needed at all. Certainly we don't even need to mention it at this 
point. The thing I'm most keen on is avoiding any side-effects we 
don't absolutely need. If we really want to treat a URI as a stream 
in a particular set of circumstances, then obviously retrieving 
information (or the stream) is useful. Otherwise, we shouldn't touch 
the network unless we *have* to.

Moreover, I don't think we'll ever get to the point where we can 
always eliminate applications which don't understand a URI handler 
thing, whatever that thing may be.

So we can usually expect to handle, for instance, 
http://example.com/a-jpeg-image by downloading it to 
/tmp/example.com/a-jpeg-image.jpg, then handing that filename to the 
app.

But anyway...

URIs have:

1) A Scheme.
2) A resource.

I think that's actually all that's common about them.

The resource has:

1) A possibly empty set of MIME types it 'naturally' falls into.
2) A method for obtaining a stream in one of these formats. 
(Unavailable if not naturally streamable.)
3) A method for generically launching a handler. (Probably based on 
the scheme).
4) A method (or interface) which treats the resource as a container. 
(Unavailable in most cases?).
5) A method for coercing a stream out of it.  (As a last resort - may 
return a stream even when the resource reports an empty list, may 
just generate an error.)

I've written these roughly in order of preference of trying them, 
although to be fair, that order changes depending on context - as in, 
what the user is apparently trying to do.

I think it's safe to fold the base resource interface into the URI 
interface, since the two are effectively indistinguishable, but I've 
left them seperate above.

Next, an application needs to advertise:

1) The schemes it understands, if any. Lack of any schemes to 
understand would indicate it only understands bare filenames (or, if 
you prefer, local-only 'file' scheme URIs relative to the working 
directory.)
2) The kind of URI handler it can be. So Subversion, DAV, webbrowser, 
sound recorder (for our /dev/dsp case)

That's all, but there's a gotcha: We need to have, for want of a 
better word, macro-expansion in the list of schemes, because there's 
wrapper systems (like GNOME's VFS, KDE's kioslaves, etc) which handle 
a consistent set of schemes. So an application which supports them 
should just say, oh, I dunno, 'urn:xdg:scheme-set:gnome-vfs' or 
something, and that gets looked up recursively. And yeah, that'll be 
endless fun if/when GNOME and KDE's VFSalikes end up supporting each 
other as a subset.

> If we agree on these points, we can move on to the fun part: 
> talking about
> pre-existing implementations, like those of nautilus, gnome-vfs, 
> netscape,
> mozilla, mailcap, wget, wvstreams, KDE kioslave, FUSE, and how to 
> make them
> play nicely together.  It could be a very interesting project.
> 
> 
It means turning the entire lot into stuff that accesses a wide range 
of interfaces via a huge bunch of wrappers, I think, if you want 
common code.

> (Avery's mind begins contemplating a UniURI or something.)

If you can then present it as a kioslave/gnome-vfs plugin, that'd be 
great.

It seems to me we've three things to do here.

1) Nail whether we want to try to 'relaunch subversion' (and similar 
tasks).
2) Sort out cross-desktop URI handler application preferences on a 
per-scheme basis. (Because it's easy, and can be done quick - it 
should end up being more or less a search and replace on the MIME 
preference stuff.)
3) Attempt some kind of universal streamable/container URI VFS plugin 
thing.

The key would be sorting out the first two - at that point, we can 
start to be able to do interesting things like right click on a 
desktop file holding a link to a subversion 'http' repository URI, 
and select "Open as folder", and be reasonably sure it'll work sanely 
no matter what desktop we're using.

Incidentally, I do wonder whether this urn:xdg:uri-handler stuff I'm 
hypothesizing is a close analogue - or even the same thing - as the 
MIME actions stuff.

You could have urn:xdg:app-capability:stream:hardcopy for 
applications capable of printing a particular document type, or 
recording a CD from audio, or whatever. Not sure if it's that 
generalizable, but urn:xdg:app-capability:stream:view:read-only would 
presumably say "Play", "Read", "Show", etc depending on the media 
type in the menus, whereas urn:xdg:app-capability:stream:view could 
*also* show "Edit", etc. I'm more or less thinking aloud here, 
though, and I can't remember what the state of the actions stuff is 
right now.

Dave.