---- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> > > > Would you consider : >> .... > > For what year? ;-) There has been a lot of work on James v2.1, and it > should be put out as a release. For a version "3", your comments make sense > to consider.
That is why I was suggesting 2 branches. One focussed on scalability(future) and another on stability(now) and separate releases focussed on these. > Will you be around to help? :-) Not sure, but I hope I can. :-( There are some pieces I can contribute that have worked for me (I actually use these) - Scheduler - Better connection management and SSL library. I think James should architect for scale. Maybe start with bare bones protocol handlers and add pieces only if they don't hamper scalability. Redisgn or drop pieces/ideas that hamper scalability. I don't think this would be an incremental effort from the current architecture. The upside is James scaling to enterprise/ISP kind of load. Even if this is not done, it would be nice to talk more about the scalability limitations imposed by current architecture. For instance, mailets/linear processors are powerful but what can be done to safely distribute processing across machines/processes. Can some form of messaging/workflow be used instead of linear processor ? > > As I understand the release plan proposal, the idea is to put out a stable > release on the current code base, followed by preparing for potentially > major revisions. Sound like a good idea. Harmeet -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
