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...
----------------------------
|
