james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harmeet Bedi" <harm...@kodemuse.com>
Subject Re: JavaMail for storage?
Date Sun, 06 Jul 2003 15:50:29 GMT
----- Original Message -----
From: "Darrell DeBoer" <darrell@apache.org>
> So far,
> I've been developing my own "connection-aware" Mailbox API, which could be
> implemented on top of JNDI, and (with modification) on top of JavaMail.
> continue to investigate...

That'll be the third API for accessing repository. SMTP/POP3 have one API,
NNTP has another API, IMAP will have another one. If you do make an API and
think it is the right set in long term, do think about what it would take to
move the rest to it.

Another thing - May I suggest if your intent is to have API/SPI like model,
document the intent well and separate repository API for IMAP from
implementation of repository and tie the two through a formal SPI.
As an example - I had made NNTP Repository Block to separtate protocol from
underlying repository implementation/abstraction but over a period of time
the separation eroded. One of the main reasons may have been lack of formal
documentation of design and also the Implementaion of repositories did not
follow API/SPI model. I had thought API/SPI was too cumbersome, but in
retrospect it would have been good and allowed communication of design and
changes more easily.
Darrell, hope this info is somewhat useful, just hoping that a past pitfall
doesn't get repeated. However do your thing at full speed. Having IMAP would
be awesome.

Ideally one standard Mail Repository would have be sufficient for all but it
is often not that easy to have that before all the requirements are known.
If James wants to be like exchange, complete requirements knowledge will
take long.
The repository abstraction should ideally be very flexible to accomodate
requirements as they are known. My favorite has been a lighweight/simplified
JNDI like API  or something like Slide Repository API. Problem with that
idea has been too general API, lack of OO structure and lack of Mail


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message