Danny and Harmeet, > Peter is the release manager, and has already posted a plan, and had it > approved by Vote. > Just where we are now at is not claer to me, but AFAIK we're progressing > in the right direction.
With the exception of the current -1 of features discussed in the release plan, yes we are. We're delayed date wise because of the current discussion. > > Here are some ideas. > > - Have a single, standard repository API. Noel, others have > > mentioned JNDI. > > If you wait on this 'till after the release I've got some repository > suggestions to make related to the Mailet API. > Basically we need to have a either: > > a) standard repository descriptor, and the URL we use seems to fit that > bill well, > or > b) mailet uses named repos and repository definition is left to the > application, > > and repository access has to be via MailetContext using the URL, > alternatively we have named repositories. > I vote heavily for a) over b) having had a system running using it, as it > allows mailets to dynamically define their own repositories. > > This removes James' mailets' "backdoor" avalon dependance. Discussed and agreed to push back to after the release in email discussions prior to the release plan. > > - Move all protocols including NNTP to use that repository API. > > Move NNTP to use a "newslet" structure and the mailet repository system to > define repositories, this also allows news to be processed, say for news- > >mail. > > > bearing all of that in mind I'm not concerned. Discussed and agreed to push discussion/changes back to after the release in email discussions prior to the release plan. My work on NNTP prior to the release was just an attempt to get it into minimal compliance with the spec. As I've stated before, I want to attract more contributors to the project and I believe that having a non-functioning service as part of the release build was somewhat embarrassing. > > - IMAP Server support. > > Already expected to be part of next cycle. Discussed and agreed to push discussion/implementation back to after the release in email discussions prior to the release plan. Having now examined the IMAP server code at length, IMHO it will take at least a month of dedicated developer effort to bring it up to spec. Certainly possible within the context of rev++. > > - Test Bed to check RFC compliance, performance and stability. > > Also already mooted for next cycle Discussed and agreed to push discussion back to after the release in email discussions prior to the release plan. > > - Experimental MS Exchange Protocol Support. > > +0 I don't know enough about this, but if its experimental, then fine. No idea what this is, but you're free to check in a new proposal at any time. Just create an appropriate directory/build structure under proposals. You can announce it on the list, and attempt to attract developers to work on it. That's what proposals is for. > > - Move away from Avalon/Phoenix. There has been some talk on this > > topic. We > > could keep the framework part and not use Phoenix if this is a sensible > > goal. > > If we fork james for this, and allow a non Phoenix version to develop in > parallel then Ok, otherwise -1 This is a total -1. If someone wishes to take James and fork, that's their prerogative. But I certainly don't want to spend time and effort supporting them. This would constitute a real design change, and one without any actual apparent motivation. The release version of James takes advantage of the Avalon Framework in general and Phoenix in particular. Certainly (as was discussed extensively in July and August) i) James doesn't need to be dependent on Phoenix - it should be able to run in any container, although not all features will necessarily be available. ii) The Avalon Framework is a good thing for the server internals. It makes life much easier. --Peter -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
