> Users are going to want to extend James' Message Store Model.
> A single interface that acts like a "Virtual File System" of
> soughts will make it easier for them.
> This interface would deal with only the serialization and
> retrival of data.
We already have this interface: MailRepository.
We simply should deprecate the MailRepository (we can always use the
SpoolRepository instead) and create a new MessageRepository interface.
> Maybe we can get it to the point that a user writing a single
> class implementing the MailStore interface is all that is
> needed to port James to a new database system or file format?
> As with some other message APIs?
MailStore has been removed in the current trunk because it was not
necessary.
We already have "Store" as the main object (let's say "repositories")
factory interface.
In my current james (patched trunk) I have this interface for
MessageRepository:
/**
* Interface for a Repository to store MimeMessage.
*
*
*/
public interface MessageRepository {
/**
* Stores a message in this repository.
*
* @param mc the message to store
* @return the key to later retrieve this message
*/
String store(MimeMessage mc) throws MessagingException;
/**
* List string keys of messages in repository.
*
* @return an <code>Iterator</code> over the list of keys in the
repository
*
*/
Set keySet() throws MessagingException;
/**
* List key,message touples in repository.
*
* @return a <code>Set</code> of Map.Entry representing
* messagekey => MimeMessage
*/
Set entrySet() throws MessagingException;
/**
* Retrieves a message given a key. At the moment, keys can be obtained
* from list()
*
* @param key the key of the message to retrieve
* @return the mail corresponding to this key, null if none exists
*/
MimeMessage retrieve(String key) throws MessagingException;
/**
* Removes a message identified by key.
*
* @param key the key of the message to be removed from the repository
*/
void remove(String key) throws MessagingException;
}
And then I create a MessageRepositoryWrapper that provide a
MessageRepository over an "old" (currently used) MailRepository. This way
I've been able to upgrade to my interfaces while keeping the current data
(file/db structure/data).
The interface is really slim: we just need to decide wether to keep
"MimeMessage" or use a "Stream" instead.
Maybe the StreamRepository from cornerstone already implements a similar
interface. We already use it in the SMTPHandler to store the incoming
message before sending it to the spooler.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
