I'm pretty sure Bill (and the spec group in general) won't want to adjust the JavaMail API too much (I think this has been asked before). They've designed it for client use, and I think they're happy with those design approaches.

But if you're talking just implementation and room for improvement, then they probably would be open for suggestions. Perhaps figure out what we want to change most, and then sort out how to address it.

Noel J. Bergman wrote:
For the internal migration, I propose we would only use JavaMail in
LocalDelivery and the POP3 handler.  That allows us to introduce JavaMail
mail boxes without breaking the rest of James.  At the appropriate point, we
can change ToRepository and the rest of the code.  Basically, it means that
work can start on this process now.
Are you suggesting we maintain two implementations of the mail repository during this interim? Can you go into a bit more what you mean by this interim migration step?

--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to