Serge Knystautas schrieb:
The biggest design deficiency of Javamail is the lack of interfaces.
That's why
using javamail means being limited in hierarchy, and being unable to
completely
replace implementations.
This is an interesting point... should we create interfaces that
mirror the method signature on JavaMail, and make a proxy impl that is
wraps the JavaMail impl?
I don't think we need complete JavaMail in the background. But many things will
be similar because of similar requirements. So we shouldn't do things completely
different if there is no need to.
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.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
