Folks, What I'd like to do is see if we can have a bit of structure to the James v3 development dialog without impeding people's ability to work. Otherwise everyone will be talking about everything at once without really getting anywhere. And once we have some consensus on how we'd like to proceed on a given subject, then we can move onto other items while people are coding the agreed upon solutions.
To start, I've updated the JamesV3/Requirements page. I've noted on it what appear to be the minimum requirements for James v3. Nothing is cast in stone. These are just talking points. I've also added work that is already underway; specifically, Serge's work with JNDI. ref: http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/Requirements The /Requirements page is distinct from the /Plans page, which is more of a wish list with commentary. I'd like to keep the requirements page pared down to what we must do, not what we could do. At some point we'll create a separate page for the work that is done or in-progress, but for the moment, I thought it would be helpful to keep those items here. Everyone will have their own ideas of things that they want to work on. Personally, I believe that the big items that must be addressed because they impact everything else are the User and Message stores, along with User and Mail attributes. Once those are squared away, services, matchers and mailets can be coded to them without ad hoc techniques or too much concern about change. In terms of priority, I put Mailet API *structural* changes at a higher priority than other changes, because of their pervasive nature. But, again, that's my view. I added a page on Mailet Configuration. I just tried to collect the various proposals that have been put forth so far. I left my old one out, thinking that the current ones provide sufficient fodder for discussion. ref: http://nagoya.apache.org/wiki/apachewiki.cgi?action=edit&id=JamesV3/MailetCo nfiguration The Wiki is used as a white board -- a persistent URL -- where people can prepare and revise their proposals, highlight some of the pros and cons. We'll discuss them here, but we can follow the state online. When we agree on something, we'll leave the agreed upon solution on the page, and remove (or move) the discarded approaches. Right now the Wiki represents my personal views, and my best attempt to record other people's views as I understand them. Until we all agree, the Wiki should not be taken to record an consensus of the James project. Are there other *requirements*? Let's discuss (and record) them. Do you have an issue with something you see recorded? Raise it for discussion, and we can record the revisions. Etc. I look forward to replies, including which topic folks would like to achieve consensus upon first so that people can get to work on it. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
