MIME message parts from backends (specifically IMAP)

MIME message parts from backends (specifically IMAP)

[Steinar Bang]

Would it be possible to change the backend interface, to allow access
to different parts of multipart messages?

The reason I'm asking this question, is IMAP, and the possibility to
utilize one of IMAP's features.  IMAP lets you access the parts of a
multipart message separately (ie. the IMAP server parses the MIME
message and allows you access to the different parts (UoW imapd
currently does this, I'm told)).

The advantage of this, is that you can decide to download the text
parts of a message, but leave that 8MB MPEG attachment on the server
until you're on a LAN.

I tried to make use of this, using IMAP with Communicator 4.  But it
turns out that this MUA does it's own MIME processing, and always
fetches the entire message to do so.

One way to make use of this feature, would be if there was an IMAP
compliant way to make the server replace body parts with standin body
parts that use the URL access type for message/external-body (as
defined in <URL:http://ds.internic.net/rfc/rfc2017.txt>) and put the
IMAP URL
     <URL:http://www.internic.net/internet-drafts/draft-newman-url-imap-10.txt>
for said message part there.

However:
  1. this would require IMAP servers to do this, and I don't think
     they do, or can be persuaded to do so using an IMAP compatible
     way 
  2. this doesn't do away with the need for an IMAP Gnus backend to be
     able to access a message part individually


- Steinar

PS. I can hear Rich gritting his teeth over this, already...:-)

Re: MIME message parts from backends (specifically IMAP)

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> Would it be possible to change the backend interface, to allow access
> to different parts of multipart messages?

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: MIME message parts from backends (specifically IMAP)

[Steinar Bang]

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

> Steinar Bang <sb@metis.no> writes:
>> Would it be possible to change the backend interface, to allow access
>> to different parts of multipart messages?

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

What I was thinking (and what probably would *really* get Rich's
hackles up :-) ), was that the (mythical) MIME parsing, and support
could be moved out into the backend, and that a uniform way to access
the message parts could be used across backends.

It's just a thought, motivated by a desire to do things in a uniform
way, even if it's less efficient, and complicates some parts.

How could you actually *do* something specifically IMAP'y?  Gnus
doesn't know about anything except the standard backend operations,
does it?


- Steinar

Re: MIME message parts from backends (specifically IMAP)

[Lars Magne Ingebrigtsen]

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

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: MIME message parts from backends (specifically IMAP)

[Steinar Bang]

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

Re: MIME message parts from backends (specifically IMAP)

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In <whvhvzs6z3.fsf@norne.oslo.metis.no> 
>>>>>	"Steinar" = Steinar Bang <sb@metis.no> wrote:

Steinar> How could you actually *do* something specifically IMAP'y?
Steinar> Gnus doesn't know about anything except the standard backend
Steinar> operations, does it?

  I think IMAP'y MIME parser or data representation is good idea.  I
would like to introduce external MIME parser to SEMI.  mime-parse.el
should be rewrote to IMAP'y and should use IMAP as external parser.

  If someone will start to define abstraction and implementation of
IMAP'y MIME handling, I would like to cooperate and use code in SEMI.

-- 
tomo.