On 10/25/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > I had suggested JavaMail, but when we all did further looking, it was > observed that JavaMail is not efficient for server storage, it would tie us > to JavaMail, and worse to MimeMessage. We really want a store that deals > with streams, from which we can easily construct a MimeMessage on demand, > but can also use MIME4J without the overhead --- and parsing issues --- of > the MimeMessage class. > > If those are solvable within the context of using JavaMail for server-side > storage, fine. Alternatively, if we have a data store that works for us and > can be put underneath JavaMail when/if we want to use JavaMail, that's fine, > too. > > Might we move this discussion to [EMAIL PROTECTED] :-)
Yes it would tie us to JavaMail, but we are already tied to JavaMail. We are already inefficient, so no sense (IMO) of at least taking advantage of what the API offers. IMHO what JavaMail is inefficient at is parsing and loading messages. Conversely what this proposal entails is using for what JavaMail is better (not great) at, i.e., working as a client to a mail store. MIME4J is nowhere ready to be a replacement. It is a read-only API last I checked. -- Serge Knystautas 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]
