[Proposal] Refactoring of SpoolRepository and MailRepository

[Aaron Knauf <ak...@xtra.co.nz>]

Recently at work, the subject of upgrading JAMES to the latest release 
came up again.  This got me back on to thinking about the mail store and 
spool repository issues.  We use these at work and I am concerned that 
they are essentially private in the current stable james release.

I see that Danny has moved SpoolRepository and MailRepository into the 
mailet package.  This is a good step toward making these APIs public.  I 
still have concerns, however, over the stability of these APIs.

I don't think that I am alone in the opinion that the design of these 
two interfaces could be improved.  It would make sense to do any 
necessary refactoring *before* publishing the interface as part of the 
mailet API.  To that end, I have put together some UML describing the 
rudiments of an alternative approach.

I sent a previous iteration of these diagrams to the list before the 2.1 
release, but everyone was too busy to pay any attention at the time.  I 
figure that now is a more appropriate time.  The diagrams are done in 
MagicDraw 6.0.  I can send the model file if anyone has MagicDraw and is 
interested.

I have changed the names of many of these classes deliberately, in order 
to avoid confusion over whether we are talking about the existing stuff 
or the new stuff.  How best to fit the new model back into the existing 
codebase can be discussed once we have figured out what we think the new 
model should look like.

I haven't yet put any classes into packages.  I thought that it would be 
good to try to get buy in and design comments from the rest of you 
before going too far down the track.

Essentially, I am trying to draw a distinction between a message queue 
and a message repository.  I don't believe that the current 
"SpoolRepository extends MailRepository" design is correct.  A 
SpoolRepository is just a queue.  A MailRepository is so much more.  At 
a high level, the only interface that SpoolRepository needs in next().

I have also tried to abstract out the active component from SMTPHandler 
and SpoolRepository.  The MessageReceiver class should be able to 
provide the only threading code necessary in this model.  This is good 
from the perspective of providing a consistent approach to threading 
(not to mention code re-use).  It has the disadvantage of pushing us 
into the "blocking accept" paradigm for all MessageSources.  The 
alternative is to go for the MessageListener paradigm, however this 
moves the active code (i.e. the thread creation) back into the 
MessageSource (i.e. FetchPop, SmtpDialogHandler, etc would have to 
manage their own threads).

I have not tried to address /where/ to get handles to MessageQueues and 
MessageRepositories.  This should be discussed.  Basically, I am just 
trying to get the ball rolling.  Out of this, I need to see a way 
forward for our mailets at work that does not involve changing our code 
for every new release of JAMES.  For my own personal interest, I would 
also like to see the code improved. :-)

Cheers

ADK