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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
