james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: JavaMail for storage?
Date Fri, 04 Jul 2003 15:18:35 GMT

Can you go into more detail as to the nature of the problem(s)?  It had
looked to me that when we were going to store mail for a user, we would get
a Store representing that user's mailbox.  That is the same model we
currently use, where LocalDelivery gets the mailbox for each user to which
it is delivering mail.  That is the logical view, at least currently.

It seems to me that any alternative to JavaMail would require us to
implement all of the IMAP features without leveraging JavaMail.  For
example, Store.getPersonalNamespaces() resolves eventually to
IMAPProtocol.namespace(), which implements the RFC 2342 NAMESPACE command.
Likewise, Store.listSubscribed resolves to IMAPProtocol.lsub, which
implements the RFC 2060 LSUB command.  Regardless of how we implement an
IMAP store, we need to implement those commands (and others).  On the other
hand, since JavaMail's IMAP store is implemented using the IMAP protocol, it
defers the operations to the server, leaving us still needing to implement
those commands.

If we need an alternative, the ldapd folks have proposed reverting to an
earlier proposal to use JNDI as the single storage interface.  Serge also
has a proposal that provides a unified addressing space for message stores.

Since you are starting to take a good hard look at implementing message
stores using JavaMail or an alternative, this is a good time to work out the
details either way.

	--- Noel

-----Original Message-----
From: Darrell DeBoer [mailto:darrell@apache.org]
Sent: Friday, July 04, 2003 2:48
To: server-dev@james.apache.org
Subject: JavaMail for storage?


I'm looking into implementing persistence in the Imap2 proposal, and I'm
having a look at using JavaMail as our mailstore interface. (From memory,
that was the plan for JamesV3).

Because JavaMail is a client-oriented API, the Store, Folder and Message
classes seem to be connection-specific, where they don't make sense except
the context of a connected user.

For example, Store.getPersonalNamespaces() gets the namespaces for a user,
Folder.listSubscribed() lists all of the subfolders that a user is

In addition, a Message object has getMessageNumber() but this may be
for different users with different connections and can change when messages
are expunged.

In light of this:
1) It seems unlikely that we'll find an existing persistent JavaMail
implementation that satisfies the needs of the ImapServer, as it would need
to be able to provide a persistent Store on a per-user basis.
2) Given 1), do we *really* want to use JavaMail as our API? We will need to
implement JDBC and File-backed implementations ourselves, providing
user-aware access to the underlying repository. Does this buy us anything,
except that we don't need to come up with an API ourselves?

Has anyone got an idea of how hard this will be to implement?

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message