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. _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
