Noel J. Bergman wrote:
Stefano Bagnara wrote:
This is way past 2.4, but other than that ... :-)
1) Remove the MailRepository interface and up-merge MailRepositories in
SpoolRepositories.
Although today the SpoolRepository is a specialized MailRepository, they are
actually quite different, and should be separate. The spool could end up
being JMS, JDBC, JavaSpace, whereas the MailRepository will have different
structural and retrieval semantics.
Maybe I've not explained what I intended: currently there is no need for
the 2 interfaces. We can join them to a single (the large one) interface
and then introduce a new interface for the MessageRepository (keeping in
account IMAP needs). First simplify what you have, then introduce new
things.
I also think that, when we'll have SpoolRepository and a new
MessageRepository we should start considering the use of JMS for the
spool (clustering, multitier, transaction support, xa transactions even
mixed with jdbc).
2) Do some experimentation on the spoolrepository interface
Agreed. So lets talk about Spool and Stores, and *then* see whether or not
they end up still being the same.
- MessageKey created while storing, and not userprovided.
And separate Mail and Message. Mail is the RFC 2821 and similar attributes,
including JAMES meta-data, and has a Message. Message is the RFC 2822 DATA
(MimeMessage).
Agreed.
The new "MessageRepository" would only store Message (MimeMessage) and
not the whole Mail object (we don't need the envelope in the message
repository).
- Split store in insert / update methods.
Clarify, please
Now we user store(Mail) either to insert messages and update messages in
a repository. If the message key is already existing then we update,
otherwise we insert. if we let the repository to create the message keys
that method is no more clear, so we should use 2 different methods to
insert and update messages (mails) in the repository.
- Introduce message moving/cloning between repositories
Yes, but first look at what happens when we separate Mail and Message. We
may have multiple Mail sharing the same Message. Also, ideally, we don't
want to move messages; once we have the Message in its store, we move the
smaller, lighter, Mail.
Yes, this is an implementation detail but should fit well in the changes
above.
- Introduce transaction awarness: JMS approach could help us in this
task, they already solved this problem, maybe it's better to start
from there than inventing new things.
I have looked at it ... believe me, I have looked at JMS, JavaSpaces, LDAP,
etc. But although we can get distribution and transactional benefits, I am
still looking at plain old JDBC as being the most efficient. For one thing,
although JMS has message attributes, we don't get nice indexing on attribute
queries. And the query semantics aren't quite a match with our needs.
I never thought at JMS for efficiency: I think that transactions,
clustering and similar features always comes at a price. But I used JMS
for a while and we can learn something from that.
3) Users Repository analysis for refactoring
I'd like for us to consider adopting JNDI/LDAP. Unlike message stores,
where we want to support mbox, maildir, and other legacy message stores, we
do not really have the same requirement for user repositories. We can
standardize on one format, either using JNDI or JDBC. Both ApacheDS and
Derby can be embedded to ensure that we always have at least one
implementation. The LDAP approach makes the most sense to me.
Authentication comes via the same package.
Why not JAAS for Authentication?
BTW, I think we simply have to separate the services interfaces, then we
can create JNDI/LDAP implementations or JAAS bridges adn more.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
