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