protocol handling spec?

[Avery Pennarun]

On Wed, Aug 11, 2004 at 09:16:04PM +0100, Dave Cridland wrote:

> In practise, UNIX maps things onto files *and* directories, [...]

AKA bitstreams and lists.  So we're actually talking about the same thing
here.

> [...] and makes it very obvious that some files are special things, too.
> Like block devices.
> 
> I'm pretty sure that if I click on a block device in Nautilus or 
> Konqueror, it's not very likely to try reading in the contents of the 
> disk (or whatever), it'll look at the filename, note that it's a 
> block device, and tell me.

In fact, most file managers that I know do this by giving block devices a
special mime type: "inode/blockdevice".  Just as konqueror shouldn't try to
render any old application/octet-stream to my display, but should give up
and ask me to save it to a file, it shouldn't try to render the contents of
my block device.  Maybe there *is* something it *should* do to my
block device when I click on it, but I'm not sure what that is.  If someone
ever figures it out, I guess they can add a handler for that MIME type.

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.

> Some kind of uniform interface for dealing with URIs is essential, I 
> agree. Forcing everything to look alike is not. Trying to model all 
> resources into as few interfaces as possible is good, trying to force 
> them all into one single model is, I think, just asking for trouble.

Things should be as simple as possible, but no simpler.  This sounds good to
me.

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

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

> I don't think, in general, the user really wants to do:
>         $ cat imap://cyrus.andrew.cmu.edu/
> I do think, however, it'd be reasonable to expect a listing if the 
> user did:
>         $ ls imap://cyrus.andrew.cmu.edu/
> And it's reasonable to expect a mail reader to com up if the user 
> simply did:
>         $ imap://cyrus.andrew.cmu.edu/

Barring my usual argument about network-transparency being too dangerous to
apply to arbitrary applications that don't expect it, this doesn't sound
objectionable to me.  It's not one of my primary goals, however.  (All that
said, you can apparently already do exactly this with FUSE via its kioslave
plugin, if it makes you happy.)

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

> >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?

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

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

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

So can we agree that:

 - we don't need to standardize URI handlers for Subversion, because it's
   application-specific.

 - standardizing URI handlers (and their APIs) across konqueror, nautilus,
   and mozilla would be nice.

 - 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.
   
 - 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).
   
 - URIs and MIME types are two separate things.  They are both strings, and
   can both be looked up to return a handler object, but URI handlers and
   MIME handlers fundamentally need to support different interfaces.  In
   general, a MIME handler is usually given a URI object, but never the
   other way around.
   
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.

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

Have fun,

Avery