You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by robert burrell donkin <ro...@gmail.com> on 2007/02/04 22:47:47 UTC
[IMAP] SEDA refactoring M1
i've tagged a first milestone for the IMAP refactoring. the code runs
ok on my local IMAP server (but i will continue testing):
http://svn.apache.org/repos/asf/james/server/sandbox/tags/seda-imap_M1
if anyone else fancies giving it a try that would be really great: i'd
like to move this code into trunk once it's had a chance to be tested
and reviewed.
this refactoring rearranges the code within each ImapCommand to split
into distinct encode, process and decode phases. ImapCommand will be
retained for the moment so that it's easier to find the right place to
apply outstanding patches.
i'll be continuing the refactoring into the handler next
opinions and improvements welcomed
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] SEDA refactoring M1
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/7/07, Joachim Draeger <jd...@joachim-draeger.de> wrote:
> Hi Robert,
>
> Am Sonntag, den 04.02.2007, 21:47 +0000 schrieb robert burrell donkin:
>
> > this refactoring rearranges the code within each ImapCommand to split
> > into distinct encode, process and decode phases.
>
> That makes absolutely sense. IMO it should be even more split up into
> distinct class files.
that's the plan but i want to move the code around gradually
> I'm not sure if we need "SEDA-fication" and a scheduling processor. At
> first it could makes things even more complicated. Maybe there are
> possibilities for tuning but I don't know if they are worth the effort.
my figures indicate that i need SEDA but i can see a way to refactor
the existing code so that it can support a spectrum of concurrency
options including the SEDA i need.
> But maybe I understand better following your next steps in the sandbox.
>
> IMO having it mina-styled is sufficient. And it would mean following an
> existing API.
MINA is SEDA (they just use a different set of names from me)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] SEDA refactoring M1
Posted by Norman Maurer <nm...@byteaction.de>.
robert burrell donkin schrieb:
> On 2/7/07, Joachim Draeger <jd...@joachim-draeger.de> wrote:
>> Hi Robert,
>>
>> Am Sonntag, den 04.02.2007, 21:47 +0000 schrieb robert burrell donkin:
>>
>> > this refactoring rearranges the code within each ImapCommand to split
>> > into distinct encode, process and decode phases.
>>
>> That makes absolutely sense. IMO it should be even more split up into
>> distinct class files.
>
> that's the plan but i want to move the code around gradually
>
>> I'm not sure if we need "SEDA-fication" and a scheduling processor. At
>> first it could makes things even more complicated. Maybe there are
>> possibilities for tuning but I don't know if they are worth the effort.
>
> my figures indicate that i need SEDA but i can see a way to refactor
> the existing code so that it can support a spectrum of concurrency
> options including the SEDA i need.
>
>> But maybe I understand better following your next steps in the sandbox.
>>
>> IMO having it mina-styled is sufficient. And it would mean following an
>> existing API.
>
> MINA is SEDA (they just use a different set of names from me)
>
> - robert
Thx for clearify this. Now i understand better ;-)
bye
Norman
--
Mit freundlichen Grüßen
i.A. Norman Maurer
Systemadministrator
ByteAction GmbH
Auf der Beune 83-85
64839 Münster
Phone: +49 (0) 60 71 92 16 - 21
Fax: +49 (0) 60 71 92 16 - 20
E-mail: nm@byteaction.de
Internet: www.byteaction.de
AG Darmstadt, HRB 33271
Ust-Id: DE206997247
GF: Thomas Volkert
------------------------------------------------------
Diese E-Mail enthält vertrauliche Informationen und ist nur für den in der E-Mail genannten Adressaten bestimmt. Für den Fall, dass der Empfänger dieser E-Mail nicht der in der E-Mail benannte Adressat ist, weisen wir darauf hin, dass das Lesen, Kopieren, die Wiedergabe, Verbreitung, Vervielfältigung, Bekanntmachung, Veränderung, Verteilung und/oder Veröffentlichung der E-Mail strengstens untersagt ist. Bitte verständigen Sie den Absender dieser E-Mail unter folgender Rufnummer +49 (0) 6071 / 9216-0, falls Sie irrtümlich diese E-Mail erhalten haben und löschen Sie diese E-Mail. Der Inhalt dieser E-Mail ist nur rechtsverbindlich, wenn er von unserer Seite schriftlich durch Brief oder Telefax bestätigt wird. Die Versendung von E-Mails an uns hat keine fristwahrende Wirkung.
This e-mail contains information which is privileged and is intended only for the Addressee named in the e-mail. In case that the recipient of this e-mail is not the named addressee, we would like to inform you that it is strictly prohibited to read, to reproduce, to disseminate, to copy, to disclose, to modify, to distribute and/or to publish this e-mail. If you have received this e-mail in error, please call the sender under following telephone number +49 (0) 6071 / 9216-0 and delete this e-mail. The content of this e-mail is not legally binding unless confirmed by letter or telefax. E-mails which are sent to us do not constitute compliance with any time limits or deadlines.
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] SEDA refactoring M1
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Hi Robert,
Am Sonntag, den 04.02.2007, 21:47 +0000 schrieb robert burrell donkin:
> this refactoring rearranges the code within each ImapCommand to split
> into distinct encode, process and decode phases.
That makes absolutely sense. IMO it should be even more split up into
distinct class files.
I'm not sure if we need "SEDA-fication" and a scheduling processor. At
first it could makes things even more complicated. Maybe there are
possibilities for tuning but I don't know if they are worth the effort.
But maybe I understand better following your next steps in the sandbox.
IMO having it mina-styled is sufficient. And it would mean following an
existing API.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org