protocol handling spec?

[Avery Pennarun]

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:

 - 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".

 - A URI handler implements an API.  You give it the blob, it gives you a
   blob.

 - 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).
   
 - The returned blob, if any, gets displayed according to its MIME type.
   
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.)

> '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.

> 'imap' - [...] 

Sends a blob containing new message contents or nothing.  Retrieves a blob
containing folder contents, etc.

> 'acap' - [...]

Sends/receives blobs containing configuration data.  The data may have a
specific MIME type determining what should be done with it.

...

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 :)

Have fun,

Avery