Serge,
According to Alex's messages, he has spoken with Bill and there seems to be
some willingness to address whatever issues Alex raised. We'll have to
await details from Alex on those issues.
In any event, my point about migration is simple. We won't preserve two
implementations of the mail repository for the interim. But during initial
development, we don't have to change the spool implementation, and we really
don't need to change the ToRepository mailet, which is used to dump spam and
error in the stock configuration. At the beginning, the only things that we
HAVE to change are the LocalDelivery and POP3 handler components.
1. Change LocalDelivery and POP3 to use JavaMail stores.
Use one of the existing JavaMail stores.
2. Test, tweak, test again.
3. Change ToRepository Mailet
4. After the spooler is replaced, we can remove the current
mail repository interface. As I understand it, we also
convert our implementations to JavaMail stores.
This incremental development is intended to make sure that we have a working
server throughout the entire process.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 02, 2003 22:29
To: James Developers List
Cc: Alexander Zhukov
Subject: Re: JavaMail as the message store
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
