james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [PATCH] mbox mail repository V2
Date Mon, 18 Aug 2003 13:13:24 GMT
Noel J. Bergman wrote:
> If you are proposing that we add:

I'm suggesting that if you are hitting a performance issue because of 
the way a protocol handler works, and you see the RFC mandates 
something, you should consider adjusting your design accordingly.

>     void remove(Collection);

Sure.

> to the org.apache.james.services.MailRepository interface, and to the
> implementations, I agree.  I think that would be the cleanest solution, at
> least until we can replace/redesign MailRepository.

I haven't looked into the code much at all, just saying you should at 
least consider modifying the MailRepository class before building in 
strange asynchronous hacks to mbox to support something that is RFC 
mandated.

> What shall the Collection hold?  Our choices seem to be Collection<MailImpl>
> or Collection<String>, which match the existing remove methods.  Neither is
> exposed to the Mailet API, although this is not an issue for services.
> Collection<Mail> would be castable internally, and matches what we actually
> have at the moment.  Collection<String> is lighterweight.

I would prefer Collection<MailImpl>.  Right now MailRepository is a 
mixture of locking methods that are String parameter based and 
repository methods that are MailImpl parameter based.  Somehow the 
single remove() got both parameter, which confuses things.  I believe 
long-term we want to separate the locking and repository behavior, at 
least in the API.

> FWIW, I have to say that I am not comfortable with the lack of exception
> handling in the MailRepository interface.  Throwing RuntimeException is
> evil.  However, I don't think that a redesign is necessary to add
> remove(Collection).  The question about exception handling comes up because
> we ought to throw an exception chain for all failures, and we can't do that
> with normal Throwable prior to JDK 1.4 (hence all of the ad hoc chained
> exception classes in other parts of Java).

Sure, make a new exception type or find another good one.  Avalon has a 
nestable exception type for pre-1.4.  I would like something ideally 
that is upward compatible though since the 1.4 exception nesting is 
quite nice, and exception display (James and Avalon code) is a weakness.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


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


Mime
View raw message