It seems to me that a mail spooler need not be a repository. It does not necessarily even need to use a repository. It just needs to pull messages from a message source and submit them to a processor for processing.
In code, a SpoolRepository /is a/ MailRepository. I cannot see why this should be the case. If the source of messages used by a message spooler happens to be a mail repository, the spooler should /compose/ the mail repository.
I have attached a couple of UML diagrams that outline (at a conceptual level) how I think it could work. Before you all rush for your flamethrowers, note the word /conceptual/. Note also that this is very rough example, intended to demonstrate a decoupling of the repository from the spool. It is for discussion only and should not not be construed as a recommendation.
One immediate advantage of this approach is to do away with the need for AvalonSpoolRepository /and/ JDBCSpoolRepository. One RepositoryMessageQueue class can use *any* repository for message persistence.
Note that I suspect that a spool and a repository are not the same thing, because their purposes are quite different. I have renamed spool to queue in my model because I think that makes the difference clearer. A repository is a thing that stores messages for later retrieval. A queue is a thing that lines messages up for processing. You add a message to a queue when you want it processed. You save a message to a repository when you want to keep it for later. Two very different focuses, despite superficial similarities. IMHO, this means they are not substitutable and therefore cannot be the same class.
The re-use of MessageReceiver, MessageProcessor and MessageSource to both receive SMTP messages from the dialog handler and also receive messages from the queue/spool is just something that I thought might be interesting. I haven't thought about it too hard, so be gentle with your flames! ;-)
Cheers
ADK
Noel J. Bergman wrote:
Charles Benett wrote:With regard to the future, providing a maildir implementation is fine but I'd recommend keeping the interface general enough to support other implementations. There were questions about the operation of IMAP versus POP3 which suggested they need different mailbox functionality. When we get to that stage, I guess we need to think about the design requirements for the 4 different mail repositories: SMTP spool, POP3, IMAP and NNTP.Absolutely. My take on repositories is: We want a single repository interface that is suitable for all message stores, including POP, IMAP and NNTP. We need an abstract interface capable of supporting search and multiple providers. Personally, I want an interface that can be optimized by providers, e.g., if we are using a JDBC provider, I want to be able to leverage SQL queries as much as possible. I have some ideas regarding this, but am postponing them until the v3 moratorium is lifted. We have this far found it convenient to use a subclass of our mail repository for spooling, but I am not sure if is the best way moving forward. FWIW, I had just written that this morning to the author of a Java maildir implementation. He may be interested in contributing to James, and mentioned some discussions he had with the JavaMail folks. Apparently there may be some willingness to make changes to JavaMail to better fit server needs, too. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
<<inline: MessageProcessingFlow.jpg>>
<<inline: MessageSpoolClasses.jpg>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
