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
<<inline: Class Diagram__Message Spooling.png>>
<<inline: Sequence Diagram__Message Spool Normal Flow.png>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
