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.
> 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).
> - Split store in insert / update methods.
Clarify, please
> - 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.
> - 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.
> 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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
