Stefano Bagnara wrote:
An alternative is (if we really care about switching implementations) is to just bundle our own JavaMail impl. Geronimo has a JavaMail impl we could code share (as you say), or whatever's appropriate.
There could be intersections. There are algorithms needed for IMAP for searching folders and messages. This algorithms are required by JavaMail, too. So maybe not use JavaMail directly, but share implementations with Apache JavaMail in a subordinate API. That way we could avoid the client overhead of JavaMail.
I don't understand how this discussion may be related to geronimo javamail implementation. When I talk of Javamail *Store* implementation I talk about a "plugin" to javamail, not a Javamail implementation itself. We already use sun javamail implementation and most of James will currently don't work so fine with different implementations, btw we don't need it anyway (now).
I fully agree that there is no reason of talking about switching JavaMail implementation. I only propose to look at the JavaMail efforts at Geronimo to see if there are any intersections to share code. E.g. searching messages and folders. I wouldn't like to utilize JavaMail for that directly.
Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
