You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/02/02 20:37:44 UTC
JavaMail as the message store
As I've mentioned, Alex Zhukov has expressed interest in working with us on
James v3. His message from mid-December said, in part:
> i have already wrote to noel that javamail while being not very
> efficient (too much parsing too early) is pretty usable for
> mailrepository in its current state, but we can try to convince bill
> shannon (person responsbile for javamail at sun - javamail@sun.com) to
> improve it. from previous talk with him i can say he is willing to
> cooperate.
Alex will also be interested to see that we're talking about using JNDI.
Since I don't know if he stayed subscribed to our list, I am cc'ing him on
this reply (and including Serge's message.
If we agree on that direction, let's talk with Alex about working with us on
it, and see whom wants to start working on converting over to JavaMail for
the store.
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.
Doing this will also allow Kenny and Darrell, and whomever else wants to
work on IMAP, to start using JavaMail and live data. I think it will
accellerate the development of our IMAP package.
--- Noel
-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Saturday, February 01, 2003 23:18
To: James Developers List
Subject: Re: Repositories
Noel J. Bergman wrote:
> Serge suggested JavaMail as the message stores interface. I'm not sure
what
> the performance is, but we do have the JavaMaildir author to help out, and
> I'm sure that he is familiar with the performance.
Basically I mean to suggest that we take the existing file and database
repositories, and rework/add necessary methods to make them implement
the JavaMail javax.mail.Folder (maybe also implement javax.mail.Store).
I think this is a good idea for the following reasons:
1. familiarity because it's a standard API
2. makes our store implementations more re-usable (our Store
implementation could be bundled as a separate jar to let a servlet app
access the database store)
3. makes it easier to drop in other mail store implementations
and more importantly...
4. If you look at the functionality/methods we need to add to our
existing mail repository interface to let it support NNTP and IMAP, you
basically have javax.mail.Folder.
> Also, please note that we're not considering JavaMail for the spool. The
> spooler needs to be high performance, but it will only move the Mail
object,
> which have a looser reference to the MimeMessage. The MimeMessage
wouldn't
> move as much as it does in the current scheme, cutting down on that
> overhead.
Agreed... spools require the Mail object, and there's the whole spooling
logic itself which most mail repositories don't need, and there's the
desire to have that implemented separately.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com/
p. 1.301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: JavaMail as the message store
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> 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.
Right, so basically just removing (and/or making abstract) the
MailRepository interface, removing the definitions of MailRepository
URLs in config.xml, and then fixing everything that uses that directly.
I'm a bit leary we're missing something, but sounds like a plan.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: JavaMail as the message store
Posted by "Noel J. Bergman" <no...@devtech.com>.
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:sergek@lokitech.com]
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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: JavaMail as the message store
Posted by Serge Knystautas <se...@lokitech.com>.
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. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org