protocol handling spec?

[Dave Cridland]

On Mon Aug  9 23:33:06 2004, Avery Pennarun wrote:
> Sorry, KDE already implemented the bizarre URI handler you speak of 
> - at
> least, it hands back the *listing* of the contents of your folder, 
> which is
> of course exactly what you want.  Then you can request (or not, as 
> you
> wish), each individual message separately.  And the URI handler 
> itself can
> handle caching.
> 
> 
Are you telling me it hands you some weird XML formatted data which 
lists every message, or it just tells you the number of messages? I 
hope it's not going as far as a UID SEARCH 1:*, let alone a UID FETCH 
1:*. That would be really horribly slow. Evolution does the for my 
own folders, when I run that, and it takes forever - I never let it 
near the anonymous IMAP servers I sometimes use with several thousand 
messages in.

But anyway, that's convinced me never to touch KDE. (Weird, because 
one of the people I keep on handing imap URIs to runs KDE.)


> The API you proposed is nice and simple, but if it were me, I might 
> want to
> add a special function for specifically composing/decomposing 
> lists.  More
> than just imap: will want to create lists of objects that I can 
> parse and
> navigate in a general way.  Of course, HTML and XML are both 
> reasonable(*)
> ways of creating general types of lists.
> 
> 
Erm. You're thinking that composing everything into XML is going to 
be faster, somehow?

I've snipped a lot here.

> (BTW, a more general URI-type mechanism is the "moniker", which is 
> simply a
> mapping of strings into objects.  When you request a moniker for a
> particular factory, it'll give you a corresponding object that 
> implements a
> particular API.  A URI is a particular kind of moniker that returns 
> objects
> implementing the URI API.)
> 
> 
Perfectly happy - indeed delighted - with most of that.

What I think you think, in these terms, is that:

1) One of:
a) Each possible interface to an object returned by a moniker 
corresponds to a MIME type.
b) All objects support an interface which provides an octet-stream, 
and has a property of a MIME type. (Sans parameters, because nobody 
likes them, eh?)

2) All possible instances of all possible URIs return a uniform 
interface. See above.

(There *is* the word Uniform in URI. It refers to the syntax and 
format of the URI, not the resource it points to.)

Here's what I think:

3) There exists an interface for an octet-stream, with a MIME type 
(with parameters, because they're useful for dispatch). This can be 
passed to, and used by, an application without the application 
needing to know about the specific method of access to the 
octet-stream.

4) URIs may provide an interface as in (3), but may not. URIs do, 
however, provide some interface with a single method which performs a 
default action for them based purely on the scheme name.

You seem to add in MIME types somewhere for no very good reason, 
possibly using them as generalized interface names. There's nothing 
wrong with that as an implementation technique, I suppose, as long as 
you remember that not everything translates into an octet-stream, and 
as long as you remember that this is really just an implementation 
detail.

By the way, pop quiz, what should you do with a "dav" scheme URI? 
(Hint, it's a registered one at IANA, and quite definitely doesn't 
have a MIME type...)

> > If I were to click on that, I'd basically expect my mail client 
> to pop
> > open, open that folder, and finally find your message, and 
> display it.
> > (Actually, it can, [...]
> 
> Erm, so it already works, and you're still complaining?  In that 
> case, your
> problems are beyond my ability to solve.
> 
> 
No, it works merely because I've told GNOME to fire off my email 
client whenever it's asked to launch an imap scheme URI. That's dumb 
handling - GNOME itself doesn't know anything about imap URIs other 
than they start with {'i','m','a','p',':'}, so it can't know that 
some IMAP URIs are accessible as an octet-stream, and others are not.


> > but that's an aside - I expect this to happen everywhere, not 
> just on my
> > carefully mutilated system here.)
> 
> So get the gnome/kde maintainers to accept your mutilations into the
> standard distribution.  It seems clear that their API is already 
> quite good
> enough to do what you want; you just want it to be the default.  
> More power
> to you.
> 
> 
GNOME has all the functionality needed to launch arbitrary URIs. It 
doesn't know, however, and I have no way of telling it, that some 
URIs are reasonable to treat as filenames. (Or whichever your 
preferred nomenclature is. Data addresses?)

Worse, if I did tell GNOME, KDE wouldn't know. Nor Rox.


> > That's the body of your message. It does have a natural, 
> unforced, > no-hammer-required MIME type, of 'text/plain; 
> charset="us-ascii"', in > fact.
> 
> The MIME type of an email message retrieved from any URI, including 
> imap:,
> should be message/rfc822.  When you display such a message, you 
> should
> expect it to pop up in some sort of "normal" mail reading program or
> component, not just a text viewer.  Of course, you could also 
> configure your
> "default viewer" for that type of object to be a text viewer, since 
> it
> happens to be a text file.
> 
> 
Reread the URI. It's pointing to the TEXT section of your message, 
which was precisely the MIME type *you* set it to be, and I merely 
quoted off the server. Not message/rfc822, text/plain; 
charset="us-ascii". Like what I typed, in fact.


> > I would, however, get annoyed if I couldn't, when in a word 
> processor,
> > import your message text by specifying that URI.
> 
> This is why your IMAP client is the URI handler, and your mail 
> reader is the
> MIME handler.

I strongly suspect that would lead to a truly revoltingly slow mail 
reader.

Dave.