Re: [Evolution] Imap & Attachments

[Not Zed <notzed ximian com>]

On Tue, 2003-07-15 at 03:24, guenther wrote:
> > > AFAIK there is currently no way of not downloading attachments. However,
> > > as the IMAP code is planned to be rewritten for 1.6, maybe this will
> > > make it in the new code as an option?
> > >
> > > Jeff, what do you think?
> >
> > this feature is actually already implemented, however what is probably
> > happening is that the attachment parts are not tagged with an
> > appropriate Content-Type an so evo says "I have no idea what mime-type
> > this part is, so I better sniff it" and so in order to do that it has to

Well afaict (from when i was working on the display rewrite which i
really need to get into cvs soon) the code should only do this if the
attachment is already downloaded (i.e. local), otherwise it just treats
it as unknown ...

Its a different case if the disposition on the attachment is 'show
inline', its always downloaded in that case (and sniffed if required).

> > download the particular attachment. This should only be happening if the
> > Content-Type is application/octet-stream tho.
>
> What I (and probably Axel) was thinking of would be an option, to never
> load attachments, until I willingly requested so. (Then use the cache,
> as currently, so I do not have to load it everytime I wanna see it.)

This would only cover attachments right?  (e.g. not inline pics in html
stuff?).

We could just add a very trivial-to-implement 'dont show attachments
inline by default' option.  Which is probably the crux of the issue.

> > anyways, for 1.6 we have some ideas on how to improve this. IMAP allows
> > us to only download a substream of the mime part, and so we plan on
> > doing this when we have to sniff (like maybe the first 1K or maybe less
> > - we could probably get away with just the first 100-200 bytes, so maybe
> > we'll only grab that much?)
>
> Jeff, please put that into the draft for the rewrite. :-)

Well as above, imho we shouldn't be doing any sniffing up dark crevices
like that :)

But i want to do the subfetch thing anyway for other purposes (e.g.
better multiplex the server connection) which will probably make
sniffing a small bit implementable anyway.

> > the problem with this...is that with all the imap (and pop3 and smtp,
> > etc) server brokeness we've encountered, I'm a bit worried this will
> > cause people problems... *sigh*
> >
> > my guess is that we'll implement it and if people report that their imap
> > servers suck (like they did with POP3 servers for the 1.4 release),
> > we'll just add a checkbox or something to work around the server
> > brokeness.

Yeah will be interesting to see how well its supported.