Re: MIME message parts from backends (specifically IMAP)

[Steinar Bang <sb@metis.no>]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> How could you actually *do* something specifically IMAP'y?  Gnus
>> doesn't know about anything except the standard backend operations,
>> does it?

> We would have to add a new standard backend operation.  :-)

Or maybe add this to a standard get URL-function that can be used for
message/external-body of all kinds?

I've now figured out (I think...) what you meant by:

> Since this would be primarily for IMAP, I think it would make more
> sense to do something specifically IMAP'y.  Say, have a way to specify
> that the (mythical) IMAP backend only retrieve text parts of all
> messages by default, and then providing some way of accessing the
> remaining parts through buttons or pseudo-articles.

You mean to let nnimap do the thing the imapd currently doesn't do: 
 - Retrieve all message parts of text/*, and create a MIME message
   using the retrieved parts, and using message/external-body
   "stand-ins" for the ones it hasn't retrieved yet
     <URL:http://ds.internic.net/rfc/rfc2017.txt>
   These will have an IMAP URL pointing to the missing message part 
     <URL:http://ds.internic.net/rfc/rfc2192.txt>

And then we need a retrieval mechanism that can be called from the
MIME handling library.

Note that the IMAP backend doesn't need to be able to do MIME
parsing, since the imapd does the parsing for it.  See
	<URL:http://ds.internic.net/rfc/rfc2060.txt>
section 6.4.5, pages 41-44, for an example of how this looks, and what
information the imapd can give nnimap about the message structure.

It (nnimap) needs to be able to build a compliant MIME message, but
this is a lot easier than parsing and interpreting MIME.


- Steinar