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. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
