Re: [Logicmail-devel] Upcoming mail store services refactoring

[Derek K. <dko...@lo...>]

Note: This is more developer-in-the-weeds stream-of-consciousness

I just wanted to let you know that after a first pass at everything I 
rambled at in the last message, and a lot of thinking, I've come up with 
a much simpler and cleaner solution that I'm currently working through 
the implementation of.

Basically, it occurred to me that the original reason for all the 
nastiness in the services layer was because of the v2.0 mail store 
request implementation.  It really was nothing but a thin wrapper around 
mail protocol commands.

Everything I proposed doing in my last ramble, and a few considered 
variations thereof, was just going to add to the complexity of it all by 
building more infrastructure in the wrong layer of the application.

So here's what I'm actually working through now:

I'm creating the more complex requests *inside* the mail store layer. 
The services layer will still be responsible for cache loading (upfront) 
and updates (by intercepting mail store events).  However, the rest of 
the protocol-dependent processes are going to solely be the 
responsibility of the mail store layer.  (So far, this actually improves 
performance as well, though it still needs a lot of testing before I can 
check it in.)

I'll then be able to dramatically simply the code in 
FolderRequestHandler, and probably even remove its IMAP and POP specific 
subclasses.  I may eventually simplify NetworkMailStoreServices as well.

Hopefully, the only complicated thing I'll have to come up with a 
cleaner solution for, is chaining folder refresh operations together (or 
queuing operations after folder refreshes).  However, given that these 
big operations are now singular requests according to the mail store, I 
may be able to remove the quirky "enable/disable IMAP idle" 
administrative operations around them.

-Derek

On 08/09/2011 10:16 PM, Derek Konigsberg wrote:
> If you don't want the back-story, feel free to skip to the mark. :-)
> Oh, and sorry for the endless rambling here.  Just want to keep people
> somewhat informed, given that I know the code is being reused downstream.
>
> Ever since the 2.0 code started coming together about a year ago, I've
> been trying to figure out where to hide all the ugliness between the
> asynchronous request-based mail store layer of the application and the
> data model layer.
>
> The ugliness I'm referring to, is the code that breaks a high-level data
> model request (e.g. "load/refresh this message") into a collection of
> cache and mail store operations.  Initially, this was scattered
> throughout the data model classes (e.g. MessageNode, MailboxNode, etc.)
> and was getting out of control.

-- 
----------------------------
  Derek Konigsberg
  dko...@lo...
----------------------------