james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jira] Created: (JAMES-521) Mail/Spool/Message repositories refactoring
Date Sat, 03 Jun 2006 12:36:55 GMT
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 

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).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message