robert burrell donkin ha scritto:
On 3/14/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin wrote:
> i can understand why some people may want to store message data in a
database
> what i cannot understand is why JAMES insists that it *has* to be
> stored in a database
Uh, it doesn't. We have multiple mailstores, only one of which is DB
based.
i suspect that we've been talking at slighty cross purposes. JAMES (in
general) supports multiple backends for most protocols but not IMAP.
Please keep in mind that IMAP and mailboxmanager are FAR
(architecturally speaking) from the rest of James.
Most committers/developers here will misunderstood you on this because
Joachim worked a lot on that 2 packages but not many committers reviewed
his code or his proposals.
I suggest you to use the words IMAP and mailboxmanager more often
instead of "JAMES" when you talk about thea services ;-)
As an example, Danny's reply about storage compatibility does not apply
to the IMAP/mailboxmanager stuff, because it is experimental and only
present in our current trunk, so we don't need to provide backward
compatibility for that: in fact it would be good if we refactor and find
a "final" solution before a release, so we won't have to write
conversion tools later.
IMAP only has one implementation and IMHO the current API is tightly
coupled to a single, database backed solution for message storage.
IMHO a more powerful and flexible approach would be for IMAP enabling
to act as a wrapper managing the meta-data but delegating message
storage to a standard JAMES mailstore implementation.
- robert
Legacy James MailRepository was not enough for IMAP
IMAP started its own interfaces as a strawman to eventually be used as
the default implementation once ready.
JDBC/Torque is the only committed implementation of the mailboxmanager:
AFAIK there is no JDBC requirement on the service interface.
About the architecture of the mailboxmanager and the storage you can
read archives: as a summary what we have is what Joachim did to have it
done. If you feel you have better solutions/interfaces/architectures,
please proceed. Maybe you want to use a branch for this, or if you feel
confident on what you will do simply tag the current code and work on trunk.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
