protocol handling spec?

[Dave Cridland]

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.