protocol handling spec?

[Dave Cridland]

On Wed Aug 11 20:01:22 2004, Avery Pennarun wrote:
> On Wed, Aug 11, 2004 at 10:41:16AM +0100, Dave Cridland wrote:
> > On Tue Aug 10 19:18:11 2004, Avery Pennarun wrote:
> > >If you don't try to retrieve the URI corresponding to the folder 
> item
> > >list, there is no reason for it to do so.
> >
> > But generating a folder message list is expensive. Generating 
> part of > one is cheap.
> 
> If you want only *part* of the message list, ask for it using the
> appropriate URI (such as one that implements an imap search).
> 
> 
Well, I actually meant that asking for every contained URI is 
expensive, but asking for, for instance, the first URI, is really 
rather cheap indeed. Hence an imap folder URI (like an http URI 
referring to a DAV URI) could be viewed as a container.

> Why?  It's usually not much work, and uniform APIs can be more 
> useful than
> we think.  That is, after all, why Unix's design is so 
> convenient... because
> they mapped things into files that, until then, people figured that 
> they
> shouldn't.  I want to continue in the same direction, particularly 
> if it's
> not any extra work.
> 
> 
True, and it's a nice goal.

In practise, UNIX maps things onto files *and* directories, 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.

I'm not even terribly sure that you can actually open a directory as 
a file on Linux - I know you can on BSD.

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.

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.

> But what is that API?  Maybe it's "run this program when you get 
> this kind
> of URI".  Maybe it's the read/write blob thing like KDE has.  Or 
> maybe it's
> something else.  Do you have a suggestion that I'm missing?
> 
> 
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.

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/

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.

> The point is to separate the *retrieving* of the object from the 
> *doing
> stuff* with the object.  If done properly, the result is quite 
> elegant.

Except that retrieving a message/rfc822 via IMAP is almost always a 
very inelegant thing to do, obviously, and as for pulling across the 
URIs for every message in a mailbox - sheesh, it's no wonder you're 
thinking of using WebDAV for mail.

> > All current desktop MIME dispatching, as far as I'm aware, uses > 
> solely the top-level type and subtype, and never the parameters. 
> 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.

> > The problem is that if you grabbed the URI from subversion, or a 
> web > folder, and slung it onto your desktop, then a reasonable 
> expectation > would be to reopen it in the same way later.
> 
> I think I understand you; you're saying that http://foo/blah might 
> refer to
> a weird subversion-version-retrieval operation with lots of 
> parameters
> attached to it, if subversion was using that URI, but refers to 
> something
> totally different if my web browser was just browsing that URI.
> 
> 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.)

Dave.