> > > > 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).
Uhm, nope... ;-)
Currently, attachments are always downloaded, regardless of trhe
Content-Disposition header.
btw: What you describe even does not make sense for files, that cannot
be previewed...
I personally would like, to *not* retrieve attachments by option --
regardless of Content-Disposition header. I don't like it, that someone
else can force me to be in-operative for a long time, just by sending a
huge attachment.
> > > 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?).
Yep -- everything, that is not displayed within the text, but under it.
> > > 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 IMAP rewrite is due to what date?? ;-)
...guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
_______________________________________________
evolution maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution
