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 Mon, 11 Nov 2002 18:17:07 GMT


> I thought I'd better (re)introduce myself, as I've been inactive in
> since February or so, and there seem to be a few new names around
> is
> fantastic). I'm currently looking for work in Brisbane, Australia, and
> given
> the state of the job market I might have a fair bit of time for open-
> source
> coding coming up.

Nice to meet you.  :)  I'm Peter.

> I plan to do a bit more work on the IMAP proposal in the next few
> How
> much work, I can't be sure, and please feel free to help out, with
> contributions to code, constructive criticism, or flame mail ;).

I'd love to coordinate with you and others on this one.  I've been
looking at the IMAP code for a month or so now and have been working on
patches for a number of issues.  Among the issues I've found are:

1) Conceptual misunderstanding of the role of the message sequence
numbers.  MSNs cannot be associated with a mailbox object, because they
are a per connection, not per mailbox, concept.  It's more than possible
for two different connections to have different MSN=>UID maps for a
given mailbox.  Mailboxes should only know about UIDs.

2) Lack of handling for the "literal" string argument type.  Basically,
the spec allows (and requires in the case of
internationalization/localization support, since quoted strings are
restricted to US-ASCII) the use of {<number of bytes>} as an argument to
specify that the server should send a continuation response and take the
next <number of bytes> as the string data.

3) Mailbox name encoding (as per spec) is not supported

4) The Search command is not implemented

5) Support for the special "INBOX" mailbox alias is not present

6) Three of the commands, for no reason I can discern, are not in the
commands package.  These commands also don't seem to take advantage of
any of the encapsulated methods in SingleThreadedConnectionHandler.
This led to at least one set of malformed NO responses, and a lot of
duplicate code.  I'm assuming these classes predate the others, and
simply need to be modified/moved.

7) The SingleThreadedConnectionHandler class has bad code at the point
where commands are read off the wire.  The whole
"setCanParse/getCanParse" concept violates basic threading techniques
(if the connection handling is single threaded it's superfluous, if
multi-threaded it's a race condition) and there is a busy loop at this

8) EXPUNGE responses are being sent after command completion responses,
in violation of spec.

9) MSN/UID set handling was incorrect - using a '-1' as an end delimiter
in some cases as opposed to producing a correct range.  No real reason
to do this - the comment about Microsoft Outlook's behavior is not
correct, as Outlook was behaving according to spec.

10) Comments are almost wholly absent.

11) Information is duplicated between the ImapRequest and ImapSession

12) Despite not being ConnectionHandlers, many of the command objects
extended BaseConnectionHandler (all functionality was unused).  The
command hierarchy in general is a little confused, with both BaseCommand
and CommandTemplate appearing to assert central roles.  Usage and
argument validation mechanisms are not unified and, in at least a few
cases, will need to be redesigned to account for point 2 above.

13) Lots and lots of "magic strings".

14) The partial fetch (allowing one to specify octets to be fetched) is
not implemented.

15) The highest UID stuff is not currently implemented for mailboxes -
highest UID is null on start.

This is the "off the top of my head" list - I think there were a few
other issues I ran into.  I'll have to look at the code again to be
sure.  Any other issues you're aware of?

2.1 has been my first priority, so I haven't done as much here as I
would've liked.  But I do have partial or complete fixes for much of the
above - as well as proper integration with the AbstractJamesService a la
the other services.  Once 2.1 is actually out the door, I'll post my
changes to date for comment, etc.  I'd really like to see some activity
on IMAP.  Originally I was hoping to see it in 2.1, but with the number
of serious open issues and the lack of concerted effort it became clear
to me that this wouldn't be the case.  At this point I'm hopeful that it
will be part of the next release.


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