On 7/17/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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.
Sharing protocols classes requires a particular design. IMAP can be used for either but is more complex. > By the way (IIRC) the first commits in that sandbox was meant to > decouple the abstract code from excalibur/cornerstone. My thought was that the initial target would be alternative streaming platforms eg servlets >>> 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. IMAP should be relatively easy to decouple. My suggestion is that this is used as a testbed. Robert > (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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
