Sascha,
It might be possible to add "child repository" notions and operations to the
current code, but ...
What we likely want to do is start from scratch, and decide what we WANT for
a mail repository interface. Certainly look at what we have, and try to
keep some degree of source compatibility, but the Cornerstone stuff is
pretty flawed, and we really should take control over the mail repository,
eliminating Cornerstone for future use.
I would also look at the JavaMail interface. Not so much to use, but to
make sure that we provide all necessary interfaces.
In terms of implementation, I would like to distinguish between a store and
a folder, the difference being that a store is a physical thing, and a
folder is organizational. Once mail is in a store, moving it between
folders should be a lightweight operation.
We should further distinguish between message and mail, where message is the
actual content and mail refers to the JAMES content that includes a
reference to the message. We already do this to some extent, but if we are
going to revisit the mail repository, we might as well learn from our
experiences and clean things up. One thing that the separation of message
and mail clears up is that we can store many copies of the mail in different
user mailboxes, and one message. When/if that message would be changed
(POP3 does not permit, but IIRC IMAP allows), then we would copy the message
and update the associated mail item. This would also clear things up for
mailet programmers, so that they have a more clearly defined behavior, as
well as improve resource utilization in both memory and storage.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
