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: Trunk Imap vs Sandboxed Imap (Was: svn commit: r536979 [1/4])
Date Sun, 13 May 2007 13:05:09 GMT
On 5/11/07, Stefano Bagnara <apache@bago.org> wrote:
> Mainly for Robert, but maybe also others are involved.
>
> The imap we currently have in trunk is an unstable work mainy by
> Joachim. Joachim already said he is no more interested in mantaining and
> keep working on that.

that's a pity :-/

i hope that Joachim will show up again one day

> This means that only Robert is currently working on the IMAP goals.
>
> Maybe we don't need to keep 2 parallel experimental versions and we can
> stick to one. If the trunk imap was a stable/release module I would
> share your current solution, but I think we don't need 2 experimental
> modules with a single mantainer (you ;-) ).

i'm not really a maintainer and it now looks like i'm going to be
*very* busy over the next few months. the current implementations
isn't too far away (though very slow). IMHO SEDA is required for
performance but is not required for correctness. so it seems a little
pointless to abandon the synchronous version.

> If you think that seda is the way to go then my suggestion is to tag the
> trunk version and replace it with the seda sandbox (keeping the original
> package).

i haven't really begun work on SEDA, i've just been trying to sort out
a design which allows most of the components to be reused between SEDA
and synchronous implementations. SEDA is orthogonal to work needed to
the back end and the protocol codecs. once the back end and codes are
fixed, the synchronous implementation should work (though it will
probably be slow)

my latest plan is (as you can see at
http://svn.apache.org/repos/asf/james/server/sandbox/seda-imap-modular/)
to work just in an experimental module in a branch that i'll keep very
close to trunk. i think it's a little early to add this experimental
module to trunk but this arrangement makes it much easier for me to
change trunk and then merge the improvements into the branch.

once the codecs are finished, i'll create a new library module in
trunk and port both implementations to use these new codecs. same with
the processors.

this sound ok?

> PS: this is not to tell you what you have to do, but simply to tell you
> what IMHO you can do to keep things simple.

IMAP is everything but simple ;-)

- robert

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