Just read again an old thread (august 2005) about repositories, and I
think this is the right moment to do something...
The first is a concrete change, ready to go, the second and third are
topics related to refactorings I thought in past.
1) Remove the MailRepository interface and up-merge MailRepositories in
SpoolRepositories. SpoolRepository is a superset of MailRepository, they
share the same storage formats, there's no need to keep them both: we
always can provide SpoolRepositories when people asks for
MailRepositories. This is only a first step, preparing for the
introduction of a MessageRepository interface (see also imap).
2) Do some experimentation on the spoolrepository interface:
- MessageKey created while storing, and not userprovided.
- Split store in insert / update methods.
- Introduce message moving/cloning between repositories:
moveFrom/moveTo/copyFrom/copyTo: this way further optimizations could be
introduced at repository level when the 2 repositories share the storage
medium.
- 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.
3) Users Repository analysis for refactoring:
- Split Users Profile services from Authentication services
- Optional support for plain-text (or bidirectional encription) in
userrepositories to provide digest based authentications (not possible
with our SHA passwords).
- Decide how to deprecate the current "James-SHA" hash in favor of "more
used" standard SHA (don't Base64, simple hex string), and support MD5
also: this would make James more easy to integrate with shell scripts
(md5 and sha command line tools do not create Base64 hashes, but
hexstrings of the hash). Imho we could keep the current "SHA" under the
"JSHA" name to simplify the upgrade to the new method, and start using
SHA for the 40 [0-9a-z] chars sequence.
- By default our UsersRepositories will provide also the
AuthenticationService, but separating the 2 services we simplify the
integration with third party autenthication mechanisms, and improve the
modularity.
- Users should never created directly from outside and we should
deprecate usersrepository methods to store users created from outside:
at most we should provide a factory method in the service interface (I
already removed the last usage fixing JAMES-505 today, so we should
simply deprecate)
As I often say, I write this only as an high level overview of what can
be done, but we can't go too much in details for points 2 and 3 because
we'll find concrete problems/solutions only working in the code.
Comments?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
