On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
