james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Where do we go from here.
Date Fri, 25 Oct 2002 15:28:27 GMT
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.

> 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, 
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
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.

> - 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.

> - IMAP Server support.

Already expected to be part of next cycle.

> - Test Bed to check RFC compliance, performance and stability.

Also already mooted for next cycle

> - Experimental MS Exchange Protocol Support.

+0 I don't know enough about this, but if its experimental, then fine.

> - 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

Add -- proposed Mailet and related James changes --

mailet Mail support for get/set attributes
mailet mailet/matcher logging with commons logging (Being fair I'm not convinced, but will
bow to opinion)
mailet classloader needs doing
mailet dynamic mailet-application-package loading, with mailet engine capable of building
configurations from many files in a single directory.

> I think, we should first only collect all the possible things we could do
> and then figure out what it takes to do it i.e. design changes etc.
> It may also be a good idea to cap the expected time frame of next 
> release. A
> good time frame may be 6-9 months.

Given peoples tendency to come and go (We all do it) it may be difficult to police. -0


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message