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.
I would agree to use JavaMail as well. IMHO, let's just stick to one API, and when we're ready to roll-our-own to improve performance, then all our code using JavaMail can benefit instead of just the Sieve proposal or just this or that.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
