On Fri, 2007-06-08 at 17:43 -0700, Ross Boylan wrote:
> On Fri, 2007-06-08 at 20:22 -0400, Jeffrey Stedfast wrote:
> > > Why does it need to create a CamelFolder for the destination at all,
> > > assuming I keep the focus on the source folder?
> > 
> > because you need both a source and a destination folder to move the
> > message(s) to?
> > 
> > kinda hard to move messages to a folder if you don't know which folder
> > to move them to, don't you agree? :)
> All you need for IMAP is the name of the target folder, not the fuller
> representation that CamelFolder provides.  In particular, there's no
> need to fetch the headers from the destination folder, index them, etc.

It allows the destination folder to do bookkeeping that may improve
performance (e.g. caching the message, adding summary info to the cache)
as well as properly handling offline state (journal the
move/append/whatever for disconnected operation so when the user went
online and opened said folder, it could re-play the journal, etc) 

This is why I had proposed ::open() and ::close() methods on
CamelFolders... instantiate a CamelFolder object just mallocs the memory
and initializes member variables/whatever, it wouldn't open the summary
or try to sync the summary over the network until ::open() was invoked.
Later, calling ::close() would unload the summary/do whatever
bookkeeping might be necessary.

It's important to see the Big Picture(tm) when making design
decisions :)


Evolution-hackers mailing list

Reply via email to