OK. Then next step. Architecturally, this is a sound piece of refactoring. In my view, it is only worth doing if we are going to have another container to support, and further, that the new container adds real value.
To add real value the new container has to offer something that the current Mailet container lacks and cannot be upgraded to support. For instance, I believe that adding Jelly support to the current Mailet container is a better route than creating a new container. A Jelly script can benefit from the state management support built in to the LinearProcessor. A Jelly container would have to provide its own state management support or expect every Jelly script to manage its own. Conversley, Sieve would be an excellent canidate for a container as it defines its own state management. In fact its 'Test and Command' pattern is similair to James' 'Matcher and Mailet' pattern. Still, what is the real value that a Sieve container brings? Sieve suport would make James configuration more administrator friendly, a major area of concern for many. Sieve provides the flexibility of the current Mailet container expressed in an RFC compliant language (RFC 3028). This is, or soon will be, familair to administrators and has IDE support. Of course, we would need a Java implementation of Sieve first! If we had that we could also Sieve enable user mailboxes in a similar way to the Cyrus IMAP server. -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
