Mailboxmanager status

[Joachim Draeger <jd...@joachim-draeger.de>]

hi!

First of all Mailboxmanager is a working title. I decided not to use
"repository" because I wanted to make clear that it is much different
from the current MailRepository.
At the moment I would prefer MailboxService for MailboxManagerProvider,
and MailboxServiceSession for MailboxManager. :-) But we should decide
on the naming when the API is done and the final function is known.

API

Maybe you noticed there are many packages and many interfaces. I tried
to categorize and subdivide the functionality. The idea is to allow
implementations to fulfill different levels of requirements. (Imap:
everything is needed, POP3 only: less)
Probably some of them are superfluous or could be recombined. 

BasicMailbox

To find a compromise of the "too complicated" discussion I created
BasicMailbox and BasicMailboxManager. Well, they are needless for imap
but fit well to other James services and could be at least a candidate
for upcoming MessageRepository. :-)
Creating a wrapper to GeneralMailbox would be easy and would hide the
complexity. 

SessionWrapper

They do belong to the implementation but could be shared by different
backends. The goal is message number stability which is needed by Imap,
Pop3 and JavaMail. That means that the message number have to be stable
even when a message gets deleted. Renumbering is allowed only when the
client could be notified. 
And that should work on a backend that is accessed by different hosts.
The service has to react to what it finds on the DB.
To be able to deliver the required events it has to keep track of what
the client is aware and cache the known message uids. This is done in
the tracker package. 
Together with the number stability the tracker and cache are really work
in progress. Even worse: I didn't know where to go when I started
them. :-) Heavy rewriting/refactoring is needed here. But that should be
done when the API is some kind of finished. Until then it should
considered as a prototype.

Torquebackend

The goal I had in mind was allowing access to the DB by multiple hosts
and let the DB manage the locking. Same here. Not everything that had
to, already uses a transaction etc... I have many ideas how to make it
water-tight, but... API first! :-)
Unfortunately I noticed that derby support is only alpha in Torque 3.2.
One problem that exists that a db generated key can't be fetched. Maybe
we could use a custom build until 3.2.1 is out.

Roadmap

I stopped working on the number/cache/tracker/torque stuff because I
think that we should work on the API now. In the current state it would
be possible to react to substantial API changes. Even if the API and the
implementation had to be rewritten from scratch we could use the
existing stuff for reference. 
As a next step I plan to explain the current architecture and the ideas
and intents I had in mind.

greetings,

Joachim






---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org