Noel J. Bergman : > I assume that you meant MineMessage. No, MimeMessage!
> I am leaning against > using MimeMessage > for specific reasons. Please review in detail the RFC 3028 > operations. > *If* we can implement them against a Stream, I think that we > would be better > off because the MimeMessage interface really expects that at > least once you > start processing the message, it is memory resident. RFC3028 defines the commands and tests that 'MUST' and 'SHOULD' be supported, and an extension mechanism for adding non-standard ones. Therefore it specifies the minimum set of operations that a Sieve implementation must support. A useful Sieve implementation would provide a superset of the operations defined in RFC3028. We can expect the range of operations supported by James matchers and mailets to be typical of a useful set. In order not to constrain the range of possible operations, the Sieve implementation will need to expose many aspects of a mail message and it's message store, much as JavaMail does. > I'm > concerned about > performance and scalability with our Sieve implementation. > Implementing a > MimeMessage subclass that doesn't expect to be memory > resident appears to > involve largely rewriting the package. I share your concerns about performance and scalability. Certainly accepting a message in a Stream should be supported. Still, there will be occasions a MimeMessage has already been built, such as in James, so it makes sense to offer this as a means of passing the message too. The key question is should the Sieve implementation use MimeMessage and other JavaMail classes and interfaces internally, use other pre-existing ones or should we cook our own? Well, I don't know of any pre-existing alternatives, so lets stick with JavaMail v cook our own. This could be a short or a long discussion. I'll go for the short one as there has been plenty said on the subject of JavaMail already. Sieve's requirements are met by the functionality provided by JavaMail. While JavaMail isn't perfect, its hard to imagine that cooking our own solution would be less effort than fixing JavaMail's imperfections. Yes, that may 'involve largely rewriting the package', but this is still likely to be less effort than cooking our own solution. The benefits of this effort can be reused anywhere that JavaMail is used, including back in James. So, I would prefer a better wheel rather than reinvent one and stick with the JavaMail API. I would be very happy if someone delivered a better JavaMail implementation! > Thoughts? > > With respect to Serge's comment about a separate CVS > repository, we could > have james-sieve, but please be aware that sometime next > year, we will be > switching from CVS to Subversion, and probably all ASF code > will reside in a > single SVN repository. Neutral about the mechanics. See my reply to Serge. -- 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]
