* downloading attachments on demand @ 2006-04-06 20:53 Sam Steingold 2006-04-11 6:13 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Sam Steingold @ 2006-04-06 20:53 UTC (permalink / raw) Is there a way to open a message without downloading all the attachments? -- Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 4 (Stentz) http://www.iris.org.il http://www.savegushkatif.org http://www.camera.org http://ffii.org http://www.openvotingconsortium.org There is an exception to every rule, including this one. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-06 20:53 downloading attachments on demand Sam Steingold @ 2006-04-11 6:13 ` Lars Magne Ingebrigtsen 2006-04-11 15:36 ` Sam Steingold 0 siblings, 1 reply; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2006-04-11 6:13 UTC (permalink / raw) Sam Steingold <sds@podval.org> writes: > Is there a way to open a message without downloading all the attachments? If it's a multipart/mixed message, for instance, then there's probably no way to query the storage back ends for just the textual bits. At least nntp or pop doesn't support anything like that... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-11 6:13 ` Lars Magne Ingebrigtsen @ 2006-04-11 15:36 ` Sam Steingold 2006-04-11 20:26 ` Jouni K Seppanen 0 siblings, 1 reply; 13+ messages in thread From: Sam Steingold @ 2006-04-11 15:36 UTC (permalink / raw) > * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-11 08:13:26 +0200]: > > Sam Steingold <sds@podval.org> writes: > >> Is there a way to open a message without downloading all the attachments? > > If it's a multipart/mixed message, for instance, then there's > probably no way to query the storage back ends for just the textual > bits. At least nntp or pop doesn't support anything like that... All I care about is IMAP (and it appears that Evolution and Mozilla can download just the text parts and the list of attachments, not the attachments themselves). -- Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 4 (Stentz) http://pmw.org.il http://www.camera.org http://www.jihadwatch.org http://www.honestreporting.com http://www.dhimmi.com http://ffii.org char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);} ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-11 15:36 ` Sam Steingold @ 2006-04-11 20:26 ` Jouni K Seppanen 2006-04-12 4:38 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Jouni K Seppanen @ 2006-04-11 20:26 UTC (permalink / raw) Sam Steingold <sds@podval.org> writes: >> * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-11 08:13:26 +0200]: >> Sam Steingold <sds@podval.org> writes: >>> Is there a way to open a message without downloading all the attachments? >> >> If it's a multipart/mixed message, for instance, then there's >> probably no way to query the storage back ends for just the textual >> bits. At least nntp or pop doesn't support anything like that... > > All I care about is IMAP (and it appears that Evolution and Mozilla can > download just the text parts and the list of attachments, not the > attachments themselves). Yes, you can do that with IMAP. I just sent myself a message containing the word "foo", an attachment consisting of the word "bar", and my signature. Here's me querying the IMAP server about the message: a fetch 3475 bodystructure * 3475 FETCH (BODYSTRUCTURE (("text" "plain" NIL NIL NIL "8bit" 5 1 NIL NIL NIL)("text" "plain" NIL NIL NIL "8bit" 3 0 NIL ("attachment" NIL) NIL)("text" "plain" NIL NIL NIL "8bit" 12 2 NIL NIL NIL) "mixed" ("boundary" "=-=-=") NIL NIL)) a OK FETCH completed. You could almost use the Lisp reader on that... Here's how to get the first part: a fetch 3475 body[1] * 3475 FETCH (BODY[1] {5} foo ) * 3475 FETCH (FLAGS (\Seen \Recent)) a OK FETCH completed. Here's the attachment: a fetch 3475 body[2] * 3475 FETCH (BODY[2] {3} bar) a OK FETCH completed. And the final part: a fetch 3475 body[3] * 3475 FETCH (BODY[3] {12} -- Jouni ) a OK FETCH completed. (This is all documented in RFC 2060.) From what I understand about the internal workings of Gnus, you'd have to alter the backend protocol to make use of this. Instead of getting a buffer filled with a message that it can parse for MIME structure, the frontend would ask for some sort of a pre-parsed message object, with stubs for the attachments, and only if the user wants to do anything with them, would the frontend query the backend for their contents. -- Jouni ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-11 20:26 ` Jouni K Seppanen @ 2006-04-12 4:38 ` Lars Magne Ingebrigtsen 2006-04-17 15:18 ` Sam Steingold 2006-04-18 9:18 ` Simon Josefsson 0 siblings, 2 replies; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2006-04-12 4:38 UTC (permalink / raw) Jouni K Seppanen <jks@iki.fi> writes: > From what I understand about the internal workings of Gnus, you'd have > to alter the backend protocol to make use of this. Instead of getting > a buffer filled with a message that it can parse for MIME structure, > the frontend would ask for some sort of a pre-parsed message object, > with stubs for the attachments, and only if the user wants to do > anything with them, would the frontend query the backend for their > contents. Well, nnimap could just return a valid MIME document with message/external-body parts, I think. Gnus and nnimap would have to implement a special external-body scheme to download the parts, but that shouldn't be too much work... I don't use imap myself, so I'm probably not the person to implement this. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-12 4:38 ` Lars Magne Ingebrigtsen @ 2006-04-17 15:18 ` Sam Steingold 2006-04-17 15:30 ` Lars Magne Ingebrigtsen 2006-04-18 9:18 ` Simon Josefsson 1 sibling, 1 reply; 13+ messages in thread From: Sam Steingold @ 2006-04-17 15:18 UTC (permalink / raw) Cc: Simon Josefsson, Jim Radford > * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-12 06:38:01 +0200]: > > Jouni K Seppanen <jks@iki.fi> writes: > >> From what I understand about the internal workings of Gnus, you'd have >> to alter the backend protocol to make use of this. Instead of getting >> a buffer filled with a message that it can parse for MIME structure, >> the frontend would ask for some sort of a pre-parsed message object, >> with stubs for the attachments, and only if the user wants to do >> anything with them, would the frontend query the backend for their >> contents. > > Well, nnimap could just return a valid MIME document with > message/external-body parts, I think. Gnus and nnimap would have to > implement a special external-body scheme to download the parts, but > that shouldn't be too much work... > > I don't use imap myself, so I'm probably not the person to implement > this. you are the Gnus maintainer, so you might prod nnimap.el authors into doing this. -- Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 4 (Stentz) http://www.memri.org http://www.camera.org http://www.openvotingconsortium.org http://www.mideasttruth.com http://www.iris.org.il http://pmw.org.il Is there another word for synonym? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-17 15:18 ` Sam Steingold @ 2006-04-17 15:30 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2006-04-17 15:30 UTC (permalink / raw) Sam Steingold <sds@podval.org> writes: > you are the Gnus maintainer, so you might prod nnimap.el authors into > doing this. *prod* *prod* -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-12 4:38 ` Lars Magne Ingebrigtsen 2006-04-17 15:18 ` Sam Steingold @ 2006-04-18 9:18 ` Simon Josefsson 2006-04-18 16:25 ` Lars Magne Ingebrigtsen 2006-04-18 20:24 ` Ted Zlatanov 1 sibling, 2 replies; 13+ messages in thread From: Simon Josefsson @ 2006-04-18 9:18 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Jouni K Seppanen <jks@iki.fi> writes: > >> From what I understand about the internal workings of Gnus, you'd have >> to alter the backend protocol to make use of this. Instead of getting >> a buffer filled with a message that it can parse for MIME structure, >> the frontend would ask for some sort of a pre-parsed message object, >> with stubs for the attachments, and only if the user wants to do >> anything with them, would the frontend query the backend for their >> contents. > > Well, nnimap could just return a valid MIME document with > message/external-body parts, I think. Gnus and nnimap would have to > implement a special external-body scheme to download the parts, but > that shouldn't be too much work... I think we've discussed this approach before, and I'm not sure it is the right one. For example, how will this work with the various caches in Gnus? There is the backlog and the agent article cache. Maybe others? I'm afraid I don't have time to work on this. Would someone else be willing to make a stab at it? Perhaps just ignore the backlog and agent cache issues, and see if it is possible to make nnimap return only partial articles if the article is larger than x KB should not be too complex. Then add a command that asks nnimap to really download the entire article. Once this is done, we can see if it is possible to prune the agent/backlog caches correctly. Alternatively, as I believe I have proposed before, we could add a new backend interface to allow Gnus to query the MIME structure of articles, and then only request partial articles, and handle the Gnus cache coherency stuff in Gnus instead of in some nnimap-specific command. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-18 9:18 ` Simon Josefsson @ 2006-04-18 16:25 ` Lars Magne Ingebrigtsen 2006-04-18 21:12 ` Simon Josefsson 2006-04-18 20:24 ` Ted Zlatanov 1 sibling, 1 reply; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2006-04-18 16:25 UTC (permalink / raw) Simon Josefsson <jas@extundo.com> writes: > Alternatively, as I believe I have proposed before, we could add a new > backend interface to allow Gnus to query the MIME structure of > articles, and then only request partial articles, and handle the Gnus > cache coherency stuff in Gnus instead of in some nnimap-specific > command. Instead of issuing `nn*-request-article' calls, Gnus could call `nn*-request-structure' (or the like) which would return the MIME structure. `nn*-request-structure' wouldn't do any caching -- the structures should be pretty small, anyway. Then we'd need a call like `nn*-request-part' that would request some content. I don't think it would be difficult to implement this, but as I don't use imap, I'm not really equipped to do so. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-18 16:25 ` Lars Magne Ingebrigtsen @ 2006-04-18 21:12 ` Simon Josefsson 0 siblings, 0 replies; 13+ messages in thread From: Simon Josefsson @ 2006-04-18 21:12 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Simon Josefsson <jas@extundo.com> writes: > >> Alternatively, as I believe I have proposed before, we could add a new >> backend interface to allow Gnus to query the MIME structure of >> articles, and then only request partial articles, and handle the Gnus >> cache coherency stuff in Gnus instead of in some nnimap-specific >> command. > > Instead of issuing `nn*-request-article' calls, Gnus could call > `nn*-request-structure' (or the like) which would return the MIME > structure. `nn*-request-structure' wouldn't do any caching -- the > structures should be pretty small, anyway. Then we'd need a call like > `nn*-request-part' that would request some content. Yup, sounds good. > I don't think it would be difficult to implement this, but as I don't > use imap, I'm not really equipped to do so. I hope someone will step forward to work on this... ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-18 9:18 ` Simon Josefsson 2006-04-18 16:25 ` Lars Magne Ingebrigtsen @ 2006-04-18 20:24 ` Ted Zlatanov 2006-04-18 21:17 ` Simon Josefsson 1 sibling, 1 reply; 13+ messages in thread From: Ted Zlatanov @ 2006-04-18 20:24 UTC (permalink / raw) Cc: ding On 18 Apr 2006, jas@extundo.com wrote: > Alternatively, as I believe I have proposed before, we could add a > new backend interface to allow Gnus to query the MIME structure of > articles, and then only request partial articles, and handle the > Gnus cache coherency stuff in Gnus instead of in some > nnimap-specific command. Can we combine this work with the flags work we discussed a while ago (arbitrary flags/tags)? It would probably be easier to do a major backend addition like that in one effort instead of twice. It may also be worthwhile to look at the entire nn* backend system and how it's implemented in each backend. I'm sure there are lessons to be learned and code that could be rewritten for better performance or reliability. Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-18 20:24 ` Ted Zlatanov @ 2006-04-18 21:17 ` Simon Josefsson 2006-04-19 18:40 ` Ted Zlatanov 0 siblings, 1 reply; 13+ messages in thread From: Simon Josefsson @ 2006-04-18 21:17 UTC (permalink / raw) "Ted Zlatanov" <tzz@lifelogs.com> writes: > On 18 Apr 2006, jas@extundo.com wrote: > >> Alternatively, as I believe I have proposed before, we could add a >> new backend interface to allow Gnus to query the MIME structure of >> articles, and then only request partial articles, and handle the >> Gnus cache coherency stuff in Gnus instead of in some >> nnimap-specific command. > > Can we combine this work with the flags work we discussed a while ago > (arbitrary flags/tags)? I don't see much connection, actually. How would you combine these two things? > It would probably be easier to do a major backend addition like that > in one effort instead of twice. Adding a backend interface isn't that difficult. > It may also be worthwhile to look at the entire nn* backend system and > how it's implemented in each backend. I'm sure there are lessons to > be learned and code that could be rewritten for better performance or > reliability. Yup. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: downloading attachments on demand 2006-04-18 21:17 ` Simon Josefsson @ 2006-04-19 18:40 ` Ted Zlatanov 0 siblings, 0 replies; 13+ messages in thread From: Ted Zlatanov @ 2006-04-19 18:40 UTC (permalink / raw) Cc: ding On 18 Apr 2006, jas@extundo.com wrote: > "Ted Zlatanov" <tzz@lifelogs.com> writes: > >> On 18 Apr 2006, jas@extundo.com wrote: >> >>> Alternatively, as I believe I have proposed before, we could add a >>> new backend interface to allow Gnus to query the MIME structure of >>> articles, and then only request partial articles, and handle the >>> Gnus cache coherency stuff in Gnus instead of in some >>> nnimap-specific command. >> >> Can we combine this work with the flags work we discussed a while ago >> (arbitrary flags/tags)? > > I don't see much connection, actually. How would you combine these > two things? I don't mean they are directly connected, but that they both require a rethinking of the backend API. If they both require it, it's better to do a major change like that just once. >> It would probably be easier to do a major backend addition like that >> in one effort instead of twice. > > Adding a backend interface isn't that difficult. I mean the backend API. It should change to allow body structure queries and arbitrary tags. I don't think in its current form it can do either easily, but perhaps I'm wrong. >> It may also be worthwhile to look at the entire nn* backend system and >> how it's implemented in each backend. I'm sure there are lessons to >> be learned and code that could be rewritten for better performance or >> reliability. > > Yup. This, too, could require significant changes... So I would suggest combining all that work in one project instead of spreading the pain and knowledge over several projects. Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2006-04-19 18:40 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-06 20:53 downloading attachments on demand Sam Steingold 2006-04-11 6:13 ` Lars Magne Ingebrigtsen 2006-04-11 15:36 ` Sam Steingold 2006-04-11 20:26 ` Jouni K Seppanen 2006-04-12 4:38 ` Lars Magne Ingebrigtsen 2006-04-17 15:18 ` Sam Steingold 2006-04-17 15:30 ` Lars Magne Ingebrigtsen 2006-04-18 9:18 ` Simon Josefsson 2006-04-18 16:25 ` Lars Magne Ingebrigtsen 2006-04-18 21:12 ` Simon Josefsson 2006-04-18 20:24 ` Ted Zlatanov 2006-04-18 21:17 ` Simon Josefsson 2006-04-19 18:40 ` Ted Zlatanov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).