IMAP + MIME + pGnus...

IMAP + MIME + pGnus...

[William M. Perry]

Has any progress been made recently in allowing Gnus to delay retrieval of
MIME parts?  I was just pondering how to do this and thought that it would
not be too hard to have nnimap spoof the delayed portions with a content
type of application/x-gnus-external-imap with a location header that looks
like a Netscape IMAP-ish URL.[1]

Or if there is an `imap' URL standard somewhere, that would be even
better.  Could the message/external-body content-type be abused this way?

I would _really_ love to switch to IMAP, but without delaying attachments,
the appeal over and above POP is not compelling. :)

-Bill P.

[1] Mailbox://mail?fetch>UID>/INBOX>13270&part=1

Re: IMAP + MIME + pGnus...

[Simon Josefsson]

wmperry@aventail.com (William M. Perry) writes:

> Has any progress been made recently in allowing Gnus to delay
> retrieval of MIME parts?

I've played a little with it. One major problem seem to be to get it
to work together with caching, backlogs, prefetching, bookmarks etc.

> I was just pondering how to do this and thought that it would not be
> too hard to have nnimap spoof the delayed portions with a content
> type of application/x-gnus-external-imap with a location header that
> looks like a Netscape IMAP-ish URL.[1]

Yup. Another approach would be to make Gnus aware of MIME-capable
backends, ie a backend function that fetched the MIME structure of the
article, and then fetch the parts it want to display.

I'm not sure which approach create the least amount of trouble with
all caching stuff. OTOH I think the second approach is much closer to
the Right Thing, so perhaps one should try that first.

> Or if there is an `imap' URL standard somewhere, that would be even
> better.

RFC2192. This is what netscape uses, I think.

-s

Re: IMAP + MIME + pGnus...

[Steinar Bang]

>>>>> wmperry@aventail.com (William M. Perry):

> Has any progress been made recently in allowing Gnus to delay
> retrieval of MIME parts?  I was just pondering how to do this and
> thought that it would not be too hard to have nnimap spoof the
> delayed portions with a content type of
> application/x-gnus-external-imap with a location header that looks
> like a Netscape IMAP-ish URL.[1]

There is an RFC defining a URL MIME External-Body Access-Type:
	http://www.isi.edu/in-notes/rfc2017.txt

> Or if there is an `imap' URL standard somewhere, that would be even
> better.

Voilá!
	http://www.isi.edu/in-notes/rfc2192.txt

> Could the message/external-body content-type be abused this way?

Probably.  See the top URL.

> I would _really_ love to switch to IMAP, but without delaying
> attachments, the appeal over and above POP is not compelling. :)

What's holding me back right now, is lack of article editing
possiblities,... and I'm sortof addicted to reparenting...  I also
like to hack MIME types from application/octet-stream (which
MSMail/MSExchange and Lotus Notes put on everything) into something
more meaningful.

Re: IMAP + MIME + pGnus...

[Steinar Bang]

>>>>> Simon Josefsson <jas@pdc.kth.se>:

> Yup. Another approach would be to make Gnus aware of MIME-capable
> backends, ie a backend function that fetched the MIME structure of the
> article, and then fetch the parts it want to display.

> I'm not sure which approach create the least amount of trouble with
> all caching stuff. OTOH I think the second approach is much closer to
> the Right Thing, so perhaps one should try that first.

I agree.  My vote goes to the MIME-aware backend.

Re: IMAP + MIME + pGnus...

[Kai.Grossjohann]

Steinar Bang <sb@metis.no> writes:

  > What's holding me back right now, is lack of article editing
  > possiblities,... and I'm sortof addicted to reparenting...  I also
  > like to hack MIME types from application/octet-stream (which
  > MSMail/MSExchange and Lotus Notes put on everything) into something
  > more meaningful.

There has been talk on the gnus-imap list about emulating article
editing by deleting the original article and submitting a new
(changed) one.

kai
-- 
Abort this operation?   [Abort]  [Cancel]

Re: IMAP + MIME + pGnus...

[Steinar Bang]

>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE:

> Steinar Bang <sb@metis.no> writes:
>> What's holding me back right now, is lack of article editing
>> possiblities,... and I'm sortof addicted to reparenting...  I also
>> like to hack MIME types from application/octet-stream (which
>> MSMail/MSExchange and Lotus Notes put on everything) into something
>> more meaningful.

> There has been talk on the gnus-imap list about emulating article
> editing by deleting the original article and submitting a new
> (changed) one.

I know, I've taken part in it.  That was one of 3(?) alternatives.
But there never was any conclusion, was there...?  If there was, it
slipped by me.

Re: IMAP + MIME + pGnus...

[Kai.Grossjohann]

Steinar Bang <sb@metis.no> writes:

  > >>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE:
  > 
  > > There has been talk on the gnus-imap list about emulating article
  > > editing by deleting the original article and submitting a new
  > > (changed) one.
  > 
  > I know, I've taken part in it.  That was one of 3(?) alternatives.
  > But there never was any conclusion, was there...?  If there was, it
  > slipped by me.

I remember that it was added to the todo list, but that might just be
wishful thinking :-)  Simon?

kai
-- 
Abort this operation?   [Abort]  [Cancel]

Re: IMAP + MIME + pGnus...

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

>   > > There has been talk on the gnus-imap list about emulating article
>   > > editing by deleting the original article and submitting a new
>   > > (changed) one.
>   > 
>   > I know, I've taken part in it.  That was one of 3(?) alternatives.
>   > But there never was any conclusion, was there...?  If there was, it
>   > slipped by me.
> 
> I remember that it was added to the todo list, but that might just be
> wishful thinking :-)  Simon?

It's on the todo list. It can't be implemented in nnimap alone, Gnus
would have to be modified and I'm not sure what the best way to do
that is.

The different strategies discussed on the nnimap list to emulate
article replacing in nnimap all have their obvious problems (simply
because article replacing can't be done with IMAP), and I don't think
I'll be putting much effort in implementing something broken.

-s

Re: IMAP + MIME + pGnus...

[William M. Perry]

Simon Josefsson <jas@pdc.kth.se> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > I was just pondering how to do this and thought that it would not be
> > too hard to have nnimap spoof the delayed portions with a content
> > type of application/x-gnus-external-imap with a location header that
> > looks like a Netscape IMAP-ish URL.[1]
> 
> Yup. Another approach would be to make Gnus aware of MIME-capable
> backends, ie a backend function that fetched the MIME structure of the
> article, and then fetch the parts it want to display.

Hmmm... I guess you could have Gnus internally know nothing about the
actual article other than the MIME handles.  Instead of
XXX-request-article, you would have XXX-request-article-structure, and most
backends would just have a trivial wrapper of (mm-dissect-buffer
(XXX-request-article ...))

Ponder, ponder, ponder.

-bp

Re: IMAP + MIME + pGnus...

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

> Hmmm... I guess you could have Gnus internally know nothing about the
> actual article other than the MIME handles.  Instead of
> XXX-request-article, you would have XXX-request-article-structure, and most
> backends would just have a trivial wrapper of (mm-dissect-buffer
> (XXX-request-article ...))

Hmm.  Yes.  Or the backend could just send the structure to Gnus on
nn*-request-article, and all the contents could be
message/external-body-ies.  Or something.  That would reduce a bit of
the complexity, but, er, it still won't be trivial to implement...

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