protocol handling spec?
Dave Cridland
dave at cridland.net
Tue Aug 10 00:29:47 EEST 2004
On Mon Aug 9 19:16:09 2004, Avery Pennarun wrote:
> On Mon, Aug 09, 2004 at 09:25:09AM +0100, Dave Cridland wrote:
>
> > Some schemes with 'special' cases:
>
> I think you're misunderstanding the difference between the jobs
> performed by
> URIs and MIME types. It's actually easy, and if you look at it the
> right
> way, none of the examples you gave are special cases at all. Watch:
>
>
Any time someone says "It's actually easy", I always get suspicious.
> - A URI simply names a resource to which you can perform a
> transaction. The transaction is typically "send a blob" followed
> by "retrieve a blob".
>
>
Up to the end of "resource", you were doing so well.
"A URI simply names a resource".
> - A URI handler implements an API. You give it the blob, it gives
> you a
> blob.
>
>
Yes, this is true. It's also far too generalized to be of any use:
// Universal URI API.
typedef void * stuff_t;
stuff_t * url_handler( url_t * u, stuff_t * stuff );
// Note, may be called with NULL, may return NULL. Might have
side-effects.
> - Your URI API defines the content format of the blobs: "method"
> types,
> error codes, error messages, data formats, MIME types. For
> example, a
> web browser tends to display most things as html pages, so its
> URI plugin
> API should return blobs in html format (or whatever). A more
> general URI
> API (like for Nautilus or KDE kioslave) might be able to use
> more useful
> data types, such as file lists (ie. file folder contents, IMAP
> folder
> contents).
>
IMAP folder contents do not have a MIME type.
You may attempt to try to coerce one onto it if you like, depending
on the size of your Trusty Hammer Of Metaphor Forcing.
MIME types describe a chunk of static data. IMAP folders are not
static.
> - The returned blob, if any, gets displayed according to its MIME
> type.
>
What MIME type? And what's "displayed" mean?
> Let's go through your "special cases" and see how they work:
> > 'mailto' - [...]
>
> Sends a blob containing things like subject line, to address, etc.
> Retrieves nothing. (In general, you'd expect the URI handler to
> actually
> send an email in between sending and receiving the blob, but that's
> really
> none of your business.)
>
>
Using my Trusty Hammer Of Metaphor Forcing, I can just about accept
this. However, my Trusty Hammer is not very big - considerably
smaller than the planet, in fact, and thus I tend to prefer making
the model fit the data rather than the other way around.
> > 'http' - [...]
>
> Sends a blob containing a method name (GET, PUT, POST, etc) and
> optional
> POST or PUT data. Retrieves a blob containing a status code, MIME
> type, and
> data.
>
>
This would appear to be the model that everything else is trying to
fit. I didn't need to use my Hammer once this time, although it
twitched somewhat when I wondered where the method name and payload
was coming from.
> > 'imap' - [...]
> Sends a blob containing new message contents or nothing. Retrieves
> a blob
> containing folder contents, etc.
>
>
Erm, hopefully not. IMAP folders are not static. The messages are,
and their parts are, but folders change. And please, don't ever
implement some bizarre URI handler that hands back the entire
contents of a folder. That would frankly be horrible, given that it's
very unlikely the user wants to see *all* of it.
> > 'acap' - [...]
>
> Sends/receives blobs containing configuration data. The data may
> have a
> specific MIME type determining what should be done with it.
>
>
Actually, almost certainly not. It rarely has a MIME type in the case
of ACAP. In fact, I would guess that most of the time, the 'sensible'
action with most ACAP URIs would be to record the URI in some
attribute of a newly created entry in some ACAP dataset. Or more
likely still, ask the user.
> ...
>
> So anyway, you *need* two different APIs here. URI APIs
> essentially need
> "get" and "put". MIME APIs need the usual "View", "Edit", "Print",
> and
> maybe others. You might combine them into a single standard,
> because
> they're sort of related, but they would need to have them in
> separate
> chapters at least :)
>
>
No, I disagree.
Tell me how 'telnet' fits in with your plans?
I do, however, agree that *some* instances of *some* URI schemes
*may* be treated essentially as filenames. Just not all, even if you
have a size larger Trusty Hammer Of Metaphor Forcing than I do.
Others behave much more like commands.
It'd be nice, I grant you, to be able to copy a local file that
happened to be message/rfc822 into an IMAP folder, but that really is
the least of my needs. Being able to specify an individual message in
a shared folder across IRC is, however, something I keep on trying to
do, in the hope that since last week it has mysteriously become
supported. :-)
imap://dwd;AUTH=*@217.155.137.59/INBOX/;uid=7534
That's your message. 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, but that's an aside - I
expect this to happen everywhere, not just on my carefully mutilated
system here.)
imap://dwd;AUTH=*@217.155.137.59/INBOX/;uid=7534/;section=TEXT
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. I'd expect that to silently, if possible, make the IMAP
connection, pull across that part, and open it in an application
suitable for viewing plain ASCII. On the other hand, I wouldn't be
surprised if it did essentially the same as above. I would, however,
get annoyed if I couldn't, when in a word processor, import your
message text by specifying that URI.
Dave.
More information about the xdg
mailing list