[Logicmail-devel] Upcoming mail store services refactoring

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

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.

After much head-banging, I solved the problem by creating a "services 
layer" in the data model package, to act as a facade between the rest of 
the data model and the mail store.  Within it, I was able to localize 
all of this nasty code.  (This layer is composed primarily of 
"MailStoreServices", "FolderRequestHandler", and their sub-classes.)  In 
the 2.0 code, this still appears overcomplicated because the mail store 
requests are not really object-oriented.  (This lead to a mess of trying 
to match requests with conceptually-request-independent mail store 
events, since the request success/failure callbacks didn't provide much 
information.)

The first major change I did in the 2.1 (trunk) code, was to completely 
refactor the mail store requests to be fully object-oriented.  This is 
somewhat obvious due to the massive increase in the number of classes in 
the "mail" package.  Due to this, I was able to change the mail store 
services layer to follow a pattern where it only cares about the 
now-useful request callbacks when managing complex operations.  (mail 
store events are directly passed through, and just looked at for cache 
updates)

-->MARK

The actual mail complex mail store services requests (e.g. "load a 
message", "refresh a folder", "refresh a collection of folders", etc.) 
are still very ugly-looking in their implementation.  While I've cleaned 
it up a lot (see above), there are still many cases where it is getting 
messy again.  This is especially true with multiple-folder refresh (i.e. 
"check all my mail folders in the background, every 10 minutes, and 
notify on new messages").  It also seems like bugs are starting to creep 
back into these cases.  (Seen a sporadic mailbox-goes-blank when 
background-refresh is enabled, and flag changes during message load also 
causes issues.)  I really just need to clean up these process flows so 
bugs can't creep in from unexpected events.

Each one of these operations can be represented kind of like a state 
machine, and I should eventually be able to document them as such also. 
  So what I'm going to be doing, is gradually refactoring these complex 
services operations into something resembling the Java state pattern.  I 
started tonight, with the basic message loading process (which is 
anything but basic).  Once I achieve a sufficient level of stability in 
my implementation, I'll start committing code.

Most likely, this will involve some variation of the following classes 
inside the "model" package:

ServicesRequestContext - context/control class
ServicesRequestState - interface all state objects implement
ServicesMailStoreRequestState - customized abstract state object 
designed to wrap mail store requests

I'll then create subclasses of ServicesRequestContext for each complex 
operation.

Of course this may change as I work through the implementation, 
especially if I start working towards using a hierarchical state machine 
for things like multiple-folder-refresh (where I want to disable/enable 
IMAP IDLE on either end).

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