On Mon, 01 Feb 2010 11:06:34 -0800, Glenn Linderman <v+pyt...@g.nevcal.com> wrote: > Another thought occurred to me regarding this "Access API"... an IMAP > implementation could defer obtaining data parts from the server until > requested, under the covers of this same API. Of course, for devices > with limited resources, that would probably be the optimal approach, but > for devices with lots of resources, an IMAP implementation might also > want to offer other options.
I like your thought about treating memory as just another backing store and designing the API accordingly. I will keep it in mind as I go along. > On approximately 1/28/2010 6:20 PM, came the following characters from > the keyboard of Glenn Linderman: > > I guess no one else is responding here at the moment. Read the ideas > > below, and then afterward, consider building the APIs you've suggested > > on top of them. And then, with the full knowledge that the messages > > may be either in fast or slow storage, I think that you'll agree that > > converting the whole tree in one swoop isn't always appropriate... all > > headers, probably could be. Data, because of its size, should > > probably be done on demand. I hope the fact that no one is responding means that they think I'm at least on the right track :) I've committed a skeleton of the new Header classes to the lp:python-email6 repository, along with my testing framework. More test cases to come. --David _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
