Joachim Draeger wrote:
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.
Imho we don't need a *JavaMail Implementation* but we may need to write
our own Javamail "Protocol provider" of type "Store" to access a local
message repository via standard interfaces.
You discussed this in 2003 (Noel proposed it).
I think that we should write James interfaces for the HIerarchical
message repository to be easily implemented as a wrapper over a javamail
store.
As Joachim already pointed out we don't need the event mechanism and
other features exposed by JavaMail, so we can simply expose our own
interface subset based on Javamail (this is a starting point: we can
refactor this if we need it).
This will make it much more easy to change things in future and we don't
bind too much to javamail (that is not under our control).
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
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).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
