protocol handling spec?
Dave Cridland
dave at cridland.net
Tue Aug 10 02:58:45 EEST 2004
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.
More information about the xdg
mailing list