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