james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Introduction (was Re: cvs commit: jakarta-james/proposals/imap/java/org/apache/james/imapserver/commands CommandTemplate.java)
Date Thu, 14 Nov 2002 07:22:59 GMT


> > 1) Conceptual misunderstanding of the role of the message sequence
> > numbers.  MSNs cannot be associated with a mailbox object, because
> > are a per connection, not per mailbox, concept.  It's more than
> > for two different connections to have different MSN=>UID maps for a
> > given mailbox.  Mailboxes should only know about UIDs.
> You may be right, but can you give an example of where 2 different
> connections
> would have different MSN's for the same underlying mailbox. From my
> understanding, the rule for mapping MSN=>UID is strictly a contiguous
> sequence in ascending order of UIDs. This doesn't allow allowing
> mappings. The MSN=>UID mapping may change between sessions when the
> underlying mailbox has changed, which may be what you meant by
> "connections".

It's a little more complicated than this.  Consider the following

Two separate connections (sockets) are opened by clients.  Over these
connections they log in, etc., and select the same mailbox.

One user proceeds to run a series of SEARCH commands.  According to
section 7.4.1, no EXPUNGE response can be sent during this series of
commands.  This is necessary so the msns can be kept in synch between
the client and the server.  So this client maintains the original set of
msns as seen upon selection of the mailbox.

Meanwhile, the other user stores a \Deleted flag for some messages,
using a STORE.  The user then executes an EXPUNGE command, which results
in these \Deleted messages being cleared from the mailbox and a series
of EXPUNGE responses being sent.  This changes the set of msns.

Now we have two connections, with different MSN=>UID mappings.

What will happen, for a well behaved client, is that the client in the
first case will received an EXISTS response when the size of the mailbox
changes.  After completing the last sent SEARCH command and before
sending the next one, it will issue a NOOP or other command that allows
the client to reset the msn sequence.  But even this behavior isn't
required by spec.  See section 5.5 for more discussion of this.

> > 11) Information is duplicated between the ImapRequest and
> > interfaces.
> 11a. ImapSession interface is a travesty. Originally, there was no
> interface
> between SingleThreadedConnectionHandler and the commands - at least
> makes it clear what the commands are using (and not).

I've actually fleshed out ImapSession some.  I definitely don't think
the ImapCommands should be accessing SingleThreadedConnectionHandler
directly.  Basically the ImapSession now allows the commands to access
session specific data (session state, current user, currently selected
mailbox, etc.) as well as provides some basic utilities used by multiple
commands (generate an untagged response, generate an expunge response,
get a mailbox, etc.)

> a) Every command without an rfc protocol test doesn't work.
> b) Some of the commands with rfc protocol tests may not work.
>     - tests are incomplete
>     - tests fail
> c) Many browsers may not work, even when the rfc protocol tests do.
> d) Licence headers need to be full Apache licence (I think).
> e) Test suite should be updated to use regular expressions rather than
> dinky
> custom codes. (All my fault, I'm afraid).
> Plenty to keep us busy, anyhow.

Definitely.  :)  I'm looking forward to it.  But for now, 2.1 awaits


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message