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 Stefano Bagnara <ap...@bago.org> on 2007/02/01 19:38:19 UTC
Re: [IMAP] Refactoring to messaging API, MINA style
robert burrell donkin wrote:
> i found time over the last week or two to take a look at MINA and
> understand better the words it uses. i now suspect that we've been
> working towards similar architectures from different perspectives.
> [...]
> opinions?
The diagram is almost standard MINA setup. +1 for me.
What I'd like to understand better is the missing part: what is done in
each command. How does the persistence layer works, and what interfaces
are used between the commands and the persistence layer. I thought this
was the main issue of the past discussion, but if you want to start from
the seda-ification of the protocol first, I'm happy anyway.
Don't take my words as criticism: I'm happy even if you start working on
the sandbox without explaining how things works. I'll dig the code and
ask you if I don't understand something.
> what's the best approach code wise?
FWIW we did some experiment moving to seda (mina) but they are not
committed because we would need java5 for ssl support and some PMC
member didn't want to loose java 1.4 compatibility for trunk, yet.
You seems to have a good understanding of what you need, and if I
understood you right you don't want to follow the step-by-step work, so
you should simply do what you want in your own branch, ignoring current
architecture limits. My opinion is that we can decide what to do (move
to the new code, backporting some of the stuff, study a step-by-step
move to the new code) once the new code works.
So my suggestion is: start playing with it in a sandbox. I understood
you want to rewrite the whole protocol handling and the whole storage,
so it seems that you don't even need other james parts. The only (the
first) integration point would be to expose a MailRepository interface
from your storage layer, so that the James spooler could write new
messages there.
It seems you/we would like to replace the protocol handling with MINA,
to change the spooling architecture, to rewrite the storage, to remove
avalon or at least phoenix and so on.
Maybe starting a whole new effort would be much better than keep trying
moving step-by-step from current James codebase. Of course such an plan
is a big effort and should be backed by more than 1 volounteer.
> how far is the new fetch implementation from being completed?
Joachim worked on this, but in the last weeks we had no news from him.
FWIW I suggest you to start on the layer behind the commands as I think
Joachim was working on mina + antlr based codecs for IMAP.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Refactoring to messaging API, MINA style
Posted by Serge Knystautas <sk...@gmail.com>.
On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
> > i'm not sure that is necessary: it should be possible (given
> > modularisation) to work within the existing frameworks.
> >
> > - robert
>
> If this is not necessary I'm even happier: we'll have a better overview
> once the new component is ready, so go ahead!
+1
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Refactoring to messaging API, MINA style
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/3/07, Danny Angus <da...@apache.org> wrote:
> > >> If this is not necessary I'm even happier: we'll have a better overview
> > >> once the new component is ready, so go ahead!
> > >
> > > +1
>
> +1
>
> On 2/1/07, Norman Maurer <nm...@byteaction.de> wrote:
> > Ps: Im still alive :-P
>
> Great news! ;-)
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Refactoring to messaging API, MINA style
Posted by Danny Angus <da...@apache.org>.
> >> If this is not necessary I'm even happier: we'll have a better overview
> >> once the new component is ready, so go ahead!
> >
> > +1
+1
On 2/1/07, Norman Maurer <nm...@byteaction.de> wrote:
> Ps: Im still alive :-P
Great news! ;-)
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Refactoring to messaging API, MINA style
Posted by Norman Maurer <nm...@byteaction.de>.
Serge Knystautas schrieb:
> On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>> > i'm not sure that is necessary: it should be possible (given
>> > modularisation) to work within the existing frameworks.
>> >
>> > - robert
>>
>> If this is not necessary I'm even happier: we'll have a better overview
>> once the new component is ready, so go ahead!
>
> +1
>
Im very busy this "weeks". So just go ahead;-)
+1
bye
Norman
Ps: Im still alive :-P
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Refactoring to messaging API, MINA style
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
>> It seems you/we would like to replace the protocol handling with MINA,
>> to change the spooling architecture, to rewrite the storage, to remove
>> avalon or at least phoenix and so on.
>> Maybe starting a whole new effort would be much better than keep trying
>> moving step-by-step from current James codebase. Of course such an plan
>> is a big effort and should be backed by more than 1 volounteer.
>
> i'm not sure that is necessary: it should be possible (given
> modularisation) to work within the existing frameworks.
>
> - robert
If this is not necessary I'm even happier: we'll have a better overview
once the new component is ready, so go ahead!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [IMAP] Refactoring to messaging API, MINA style
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin wrote:
> > i found time over the last week or two to take a look at MINA and
> > understand better the words it uses. i now suspect that we've been
> > working towards similar architectures from different perspectives.
> > [...]
> > opinions?
>
> The diagram is almost standard MINA setup. +1 for me.
> What I'd like to understand better is the missing part: what is done in
> each command. How does the persistence layer works, and what interfaces
> are used between the commands and the persistence layer. I thought this
> was the main issue of the past discussion, but if you want to start from
> the seda-ification of the protocol first, I'm happy anyway.
the biggest short term gain (for me) would be from a scheduling
processor so SEDA-fication seems a good place to start
> Don't take my words as criticism: I'm happy even if you start working on
> the sandbox without explaining how things works. I'll dig the code and
> ask you if I don't understand something.
i like well founded criticism since it helps to develop better ideas
> > what's the best approach code wise?
>
> FWIW we did some experiment moving to seda (mina) but they are not
> committed because we would need java5 for ssl support and some PMC
> member didn't want to loose java 1.4 compatibility for trunk, yet.
IMHO there would be a consensus in favour of use of java 5 in component modules
james server splits naturally into core interfaces plus a number of
independent modules. the existing SMTP implementation could be
retained as a module for use on java 1.4 whilst the new MINA based
implementation would be available for those running java 1.5.
<snip>
> It seems you/we would like to replace the protocol handling with MINA,
> to change the spooling architecture, to rewrite the storage, to remove
> avalon or at least phoenix and so on.
> Maybe starting a whole new effort would be much better than keep trying
> moving step-by-step from current James codebase. Of course such an plan
> is a big effort and should be backed by more than 1 volounteer.
i'm not sure that is necessary: it should be possible (given
modularisation) to work within the existing frameworks.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org