james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <darr...@apache.org>
Subject Re: JavaMail for storage?
Date Fri, 04 Jul 2003 21:36:10 GMT
On Sat, 5 Jul 2003 01:18 am, Noel J. Bergman wrote:
> Darrell,
>
> 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.

Hi Noel and Serge.

A JavaMail Folder, with it's associated Message objects, represents a 
connection's *view* of the Mailbox, not a universal view. The clearest 
example is the concept of a message number, whereby all messages in a mailbox 
are numbered from 1 to N. This is available via Message.getMessageNumber(), 
and is used to access messages from a Folder. However, a message number isn't 
a message identifier, and in IMAP 2 connections may concurrently have 
*different* message numbers for the *same* message. This is because the 
EXPUNGE action can't be applied while a connection is in certain states, 
during certain command sequences (eg after a FETCH). Because of this, that 
connection's messages don't get renumbered immediately if the expunge is 
performed by a different connection.

The JavaMail UIDFolder interface provides extra methods to access the unique 
identifiers for a Mailbox and it's associated messages. We may need to add 
our own specific folder interface to get extra things IMAP needs like 
"getFirstUnread()".

Don't get me wrong, my understanding is that the JavaMail interfaces will be 
sufficient to give us what we need (with maybe a few minor additions). I was 
just musing about how much of JavaMail is *required*.

>
> 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.

I'll admit that I haven't looked at the JavaMail source, just the JavaDocs. I 
had initially thought that we were planning to use JavaMail so we could 
leverage *existing* persistent, local JavaMail implementations (like MBox, 
Maildir...). However, it seems very unlikely that we will find one that is 
designed and built for a multi-user scenario. 

Given that, I was wondering if we were buying ourselves a lot more work for 
little gain. I've not implemented a JavaMail provider, so I'm not aware of 
the complexities involved. But you're right, we're going to have to implement 
the functionality anyway; it remains to be seen how much help the JavaMail 
implementation will provide in doing so...

>
> 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

Regarding JNDI the question will be: "do we implement JavaMail on top of JNDI, 
and then use the JavaMail API?" (as well as other implementations?). So far, 
I've been developing my own "connection-aware" Mailbox API, which could be 
implemented on top of JNDI, and (with modification) on top of JavaMail. I'll 
continue to investigate...

ciao
Daz

>
> -----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?
>
>
> G'day,
>
> 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
> in
> the context of a connected user.
>
> For example, Store.getPersonalNamespaces() gets the namespaces for a user,
> and
> Folder.listSubscribed() lists all of the subfolders that a user is
> subscribed
> to.
>
> In addition, a Message object has getMessageNumber() but this may be
> different
> 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?
> --
> ciao,
> Daz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

-- 
ciao,
Daz



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


Mime
View raw message