James v3 Requirements and Planning

["Noel J. Bergman" <no...@devtech.com>]

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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

RE: James v3 Requirements and Planning

["Noel J. Bergman" <no...@devtech.com>]

Harmeet Bedi wrote:
> Noel J. Bergman wrote:
> > 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.

> - Standard repository interface.

Isn't that part of the user and message stores?

> - Move all the protocol servers to the standard repository.
> - Default IMAP to on.

Protocols do not default to on until they pass testing.  We will probably
restructure the CVS, and with some of the work that Darrell just did, it may
make it easier to re-integrate things since we don't have to load those
components when we do the distribution build.

Serge suggested that my estimate of James v3 being one year away is
realistic if we wait for everything, but he'd like something sooner.  If we
make the structural changes necessary, added key enhancements, and removed
obstacles that impede proper development of IMAP and NNTP, then there is an
argument for releasing James v3.0.  I'm not saying that a functional IMAP
server isn't part of James v3.0, but I'm accepting that we may not want to
wait that long.  So I am trying to define the minimum requirements that must
be met along the way.

	--- Noel


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

Re: James v3 Requirements and Planning

[Harmeet Bedi <ha...@kodemuse.com>]

----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> 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.

- Standard repository interface. This has been talked about. I thought Danny
had a proposal but there has been no agreement or code in proposal
- Move all the protocol servers to the standard repository.
- Default IMAP to on. Corollary is that it should work even in a narrow
sense. Maybe one can pick a one or two clients and support them.

Harmeet


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