Peter M. Goldstein wrote:
>All,
>
>Apologies for the cross-post folks - this was supposed to go to
>james-dev, not james-user.
>
>--Peter
>
>-----Original Message-----
>From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]]
>Sent: Friday, August 16, 2002 1:56 PM
>To: 'James Users List'
>Subject: What do we need to release 2.1?
>
>All,
>
>There's started to be some agitation on the james-user mailing list for
>a new release. While I don't think we're there yet, I think it is
>reasonable for us to ask (and try to come to some sort of consensus)
>what features/fixes do we feel are required for the next release. To
>kick off the conversation, I'm going to give everybody my personal wish
>list.
>
>New Features:
>
>1) IMAP - I think this one is going to be on most people's list. I'd
>like to see IMAP at an "Experimental" level. That means basic
>functionality as specificied in the relevant RFCs will be implemented.
>Certain functionality may be documented as not yet implemented, and the
>system will not necessarily have undergone load or stress tests
>
>Experimental => Stable
>
>1) TLS Support for POP3 - This is really a rather simple piece of
>functionality. I think this one should be stabilized before we release
>the next revision.
>
>Internal Documentation
>
>I know some people tend to dismiss internal documentation, but I don't
>see how a project that is seeking to attract developers can function
>without it. As such I tend to include it in the exit criteria for a
>particular release.
>
>1) All methods and instance variables should be documented. All classes
>should be documented. The documentation doesn't need to be extensive,
>but it should be present. It should include issues such as class/method
>contracts and threading restrictions where appropriate.
>
+1
>2) All public and protected classes, methods, and variables need to be
>documented using Javadoc style to ensure appropriate Javadoc
>
+1
>3) The Javadoc should build without warnings
>
+1
>4) All packages should have package documentation
>
+36365
>
>External Documentation
>
>1) Write up specific documentation addressing the top 5 issues listed on
>the TODO list
>2) Start building an organized James "manual" with common
>configurations.
>
>
This is something I've been thinging about with respect to the Merlin
based deployment. In Merlin you can create preconfigured profiles for
components and in some case totally eliminate the need for user provided
configuration. In addition in Merlin you can seperate configuration
defaults for a particular type from the configuration, context, and
logging profile.
>Avalon
>
>1) Migrate all Composable to Serviceable
>
+1
>2) Deal with the Mailet API implications by creating a ComponentManager
>wrapper for the ServiceManager. Note this in documentation, with the
>understanding that we'll be deprecating.
>
Can you expand on the issues here - keeping in mind that I don't knw
anything about the Mailet API (at least not yet).
>3) Change code so that it doesn't use the TimeScheduler
>
>Enhancements / Bug Fixes
>
>1) Include Andrei's changes to address connection handler
>performance/robustness issues.
>2) Bugs #2288, #4003, #6812, #6928, #8581, #8839, #8861, #9669, #11243,
>#11640.
>3) Address the as of yet unfiled bug about sending emails to an IP
>address.
>4) New bugs will be evaluated on a case by case basis as they are filed.
>
>Thoughts?
>
And - get in place documentation of the dependecies - componet
interdepdencies, component implementation versions, servce versions, jar
file extension depedences (including specification and implementation
versions).
Cheers, Steve.
>
>--Peter
>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
