james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: Imap status
Date Wed, 04 Jun 2008 12:44:06 GMT
On Wed, Jun 4, 2008 at 12:38 PM, Ihsiak <ihsiak@gmail.com> wrote:
> Robert Burrell Donkin pisze:
>> On 6/4/08, Ihsiak <ihsiak@gmail.com> wrote:
>>> Hello
>> Hi
>>>  I am part of a team that works on integrating James with webbased
>>> mailing solution. So far, we have sucessfully developed integration for
>>> smtp and pop3, and now we are going to work on IMAP. I know that current
>>> IMAP is not production ready - yet, so we want to work closely with you
>>> and make it better (for you) and usefull (for us). If we get permission,
>>> therewill be probably 2 persons available for about 2-3 months for that
>>> project. But before we get to that I need to know what's current stare
>>> of IMAP code, and what areas requies work. Can anyone describe it to me?
>> There are currently two IMAP implementations on trunk. One has a
>> straightforward design and is currently unmaintained. The second is an
>> experimental rewrite. This code is under active development but is
>> difficult to work with (my interest is in advanced high performance
>> mail architectures and it's an in-place rewrite since I use it for my
>> mail).
>> The main implementation is incomplete, buggy and leaks memory. The new
>> implementation works ok with the clients I use and is very close to
>> being feature complete. But the original should be fixable by
>> cross-porting.
>> Which version interests you?
> Definitely the second one (we don't want to duplicate integration work, and
> do "waste" bug fixing on the old code, and then on the new one).

good. i'll talk only the second from now on.

> We should be able to donate two persons to work on that project - can you
> estimate how long it would take to complete "feature complete" version

IMAP (as a specification) is interesting :-/

4rev1 is specified by RFC2060 and again in RFC3501. the major
difference is that STARTTLS is not supported by RFC2060 but is
mandated by RFC3501. AIUI newish clients all use RFC3501, ancient
clients use RFC3501. IMAPS works but STARTTLS is to be implemented.

STARTTLS should be straight forward but ideally want to push generic
support into the JAMES socket handling layer. any volunteers?

everything else is just about feature complete but with some areas of
buggy code which are yet to be rewritten (mainly in FETCH and APPEND).
the biggest remaining effort is going to be proving the implementation
works. this requires improving the functional test suite (and fixing
all bugs found), in particular by simulating a variety of clients.

but feature complete is a way from being production ready. the current
backend needs a complete rewrite, for example.

IMAP also has quite a number of additional RFCs which define extra features

> (count us too, but keep in mind that we have to get familiar with the code
> first).

the developers on IMAP are volunteers and many work on multiple
projects. JAMES is also into an intensive cycle of releasing
components which is my personal priority ATM. so estimates and
deadlines are difficult. there's also the question of what production
readiness means: running live on the internet is quite different from
running on a intranet protected by a firewall; serving a few dozen
users is very different from serving thousands.

but i think that 2 extra developers should be able to achieve a
reasonably good IMAP over 2-3 months.

- robert

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

View raw message