Robert Burrell Donkin ha scritto:
On Sun, Jul 13, 2008 at 9:47 PM, Serge Knystautas <[EMAIL PROTECTED]> wrote:
On Sat, Jul 12, 2008 at 1:15 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
i think we're quickly reaching a time where different agendas for
JAMES will start to come into conflict with one another. i believe
that many community problems just reflect problems with structure and
modularity. so again, i'm going to suggest a technical solution to
avoid a community problem.
i think that sometime soon, people are going to want to look at
releasing (in some form) what's in trunk but IMAP is still under very
active development. once all functions are tested, next on the agenda
is a complete rewrite of the backend code. for the last week, IMAP
failures due to changes in mime4j broken JAMES. JAMES didn't really
need to upgrade until a more stable release but IMAP requires some of
the new functions. this conflict of interests led to a week of broken
tests.
i've said before that i would really like to see the protocol handling
components moved out of JAMES server and into lightweight independent
libraries capable of embedded reuse elsewhere. this would open up uses
of these components in other environments. for example, by mixing
basic POP3 into a standard java application. the libraries would not
perform socket or thread management: they would be toolkits from which
mail servers could be built. they would have no coupling to avalon.
JAMES server 3.0 would be build up from these components adding in
container services and blending all together into a standard compliant
application. i think that this approach will increase the chances of a
3.0 release (of some sort) happening as well as allowing other
projects to reuse JAMES components more easily.
opinions?
I do not have any technical reason to keep the protocol handling
heavily tied into the server. As long as it functionality doesn't
change, I think there's merit in evolutionary rewrite of this code.
Do you see this as requiring heavy lifting with major components
rewritte? Or do you see this as a decoupling of sorts?
i see this just as an exercise in decoupling. the protocols very
nearly now just plug into the socket handling stuff.
FWIW inactive/handlerapi-experiment contained a refactoring of the
abstract protocol classes to support a push model. It was an experiment
to understand if we could have decoupled the protocol code from the
network layer so to be able to reuse the same protocol code with MINA.
IIRC after a while we (people working on that sandbox: Norman and I)
decided that it didn't worth to heavily refactor the excalibur code this
way and instead it was better to write new mina based components from
scratch not sharing the protocol classes.
By the way (IIRC) the first commits in that sandbox was meant to
decouple the abstract code from excalibur/cornerstone.
My foggy head
is telling me that SMTP and POP3 won't be too bad protocol wise but
might be tough for configuration and some dependencies (mailbox
access, user lists, etc...).
configuration is a major issue in JAMES: it ties us to avalon and
prevents use in other containers. one solution would be decouple POJOs
and leave configuration to the server.
This is an old time issue. I think the PMC already agreed that POJOing
our components removing direct avalon dependencies is a good thing.
Unfortunately, expecially for the Configuration, it is much easier to
discuss than doing. The way we use Configuration is a pattern imposed by
avalon: it is not so easy to reproduce the same behaviour with a pojo
approach unless we don't reintroduce the same pattern in custom code (I
don't think that decoupling from avalon by copy&paste its classes to our
own code is a win, so I won't suggest a similar solution) or we don't
apply major refactorings to our code.
I think we just need to see some concrete proposal (code) about this
issue: we already agree in principle that this is a good way for james.
(I'm not pushing you to do something, just referring you what was the
mood/opinion of the PMC in past)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
