james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Where do we go from here.
Date Fri, 25 Oct 2002 18:29:34 GMT

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>


Mime
View raw message