Very quick, since I need to get up at 'Dark:30, and may not be online
before Thursday.
Danny, Norman, Vincenzo and I met. Good chats.
Norman and I probably spent the most "quality" time -- from a JAMES
perspective -- working on code together. Some of the results are what he is
coding into the sandbox. More to follow.
Vincenzo has some cool ideas for AV, Bayesian and signed messages, but I'll
let him explain. Robert Burrel Donkin may want to collaborate with us on
PGP. We can add PGP-signed message support to our current S/MIME handling.
Cliff Schmidt will help us deal with the legal filings.
Spoke with Peter Royal. He'll help get us moved to MINA. We looked at the
current JAMES code. As many of you may recall, Peter is an ex-Avalon
contributor, and knows both sides of the situation.
Danny and I both spoke with the SGi folks. They'll help.
Danny and I concur that we should probably create our own
o.a.mailet.configuration package, modeled on Jakarta Commons Comfiguration
with an interface we can use and keep constant, and map that onto Commons
Configuration. Danny's argument, which I accept, is that we want control
over the interface, and can't rely upon Jakarta Commons not to change it. I
also reviewed with the Jakarta Commons Configuration with the SGi folks,
and I believe that we agree that it would be the right direction for JAMES.
We also spoke with the Derby folks, and got some tips from them, which will
result in some changes for the database schema. Also, they have a new
release coming out with in a week or so, and that would be a good time to
put out a release candidate.
Norman and I reviewed v2.2-v2.3 updates, and agree that we can put in a
default chain, although it will mimic v2.2, i.e., no fast-fail, so our new
config.xml should still define a chain, albeit with docs that the chain
configuration WILL CHANGE for future releases.
Roadmap-wise, I believe that we feel that once we're done with v2.3, the
next release will be v3. It will include the new fast-fail code, database
changes (which force the major version jump), likely Stefano's refactored
FetchMail (just needs to be reviewed and tested), and some other changes.
I'm tired, and don't recall what there were others on the list, but we're
not talking pervasive, radical, changes. We agree that we want to keep
moving AND releasing.
Concurrent, or after, would be moving to MINA, SGi and the new spool
approach, and that would probably be v4. I believe that we currently do not
want to base message storage on JavaMail, and we should start to shift
things to MIME4J when appropriate.
As an aside, I believe that we agreed that database is preferable for
everything except those things for which we use ToRepository, e.g., Spam,
Error and AntiVirus folders. The reason being that the file system
repository is much easier for admins to monitor, review and purge; whereas
the database is nicer for spooler and user mailboxes. So we can go that
route for v2.3. I still prefer dbfile, but the changes to the db schema in
v3 will address much of my preference for dbfile.
I spoke with Jason van Zyl, and although I prefer that we continue to use
Ant rather than Maven, for interim use when necessary, we can compromise by
agreeing to use the `maven ant` command and maintaining the resulting
build.xml file in svn for any JAMES project that uses maven. That command
must be run, and the resulting file updated in svn, whenever the project's
pom.xml changes. That will allow anyone to build the project using just
Ant.
That's all for now. More later, and others should respond with what they
remember, and correct me on anything that I mis-represented or forgot.
Speaking of which, attached are notes for Norman which need explanation, are
inconsistent (the same class name spelled three different ways) and
incomplete, but he'll understand (and so should most forgiving readers from
context). :-)
Cheers for now. :-)
Noel
To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Noel J. Bergman wrote:
I spoke with Jason van Zyl, and although I prefer that we continue to use
Ant rather than Maven, for interim use when necessary, we can compromise by
agreeing to use the `maven ant` command and maintaining the resulting
build.xml file in svn for any JAMES project that uses maven. That command
must be run, and the resulting file updated in svn, whenever the project's
pom.xml changes. That will allow anyone to build the project using just
Ant.

Noel, this only works for maven 1. I have been converting the server
code to maven 2. Maven 2 does not have such a plugin.

Regards,
Alan

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Alan D. Cabrera wrote:
Noel J. Bergman wrote:
>I spoke with Jason van Zyl, and although I prefer that we continue to
>use
>Ant rather than Maven, for interim use when necessary, we can
>compromise by
>agreeing to use the `maven ant` command and maintaining the resulting
>build.xml file in svn for any JAMES project that uses maven. That
>command
>must be run, and the resulting file updated in svn, whenever the
>project's
>pom.xml changes. That will allow anyone to build the project using just
>Ant.
>
>
Noel, this only works for maven 1. I have been converting the server
code to maven 2. Maven 2 does not have such a plugin.

Doh! I just found it:

mvn ant:ant

Regards,
Alan

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Am Sonntag, den 02.07.2006, 16:25 -0700 schrieb Alan D. Cabrera:
Alan D. Cabrera wrote:
Noel J. Bergman wrote:
>I spoke with Jason van Zyl, and although I prefer that we continue to
>use
>Ant rather than Maven, for interim use when necessary, we can
>compromise by
>agreeing to use the `maven ant` command and maintaining the resulting
>build.xml file in svn for any JAMES project that uses maven. That
>command
>must be run, and the resulting file updated in svn, whenever the
>project's
>pom.xml changes. That will allow anyone to build the project using just
>Ant.
>
>
Noel, this only works for maven 1. I have been converting the server
code to maven 2. Maven 2 does not have such a plugin.

Doh! I just found it:

mvn ant:ant

Regards,
Alan

Thx Alan for post this :-)

PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)

P1gmtLoj6cF6eTtYLk6E=
=zN5L
PGP SIGNATURE

Noel J. Bergman wrote:
We also spoke with the Derby folks, and got some tips from them, which will
result in some changes for the database schema. Also, they have a new
release coming out with in a week or so, and that would be a good time to
put out a release candidate.

Any update on this?
I would like to know that are the optimizations proposed by the derby folks.

Stefano

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org

Appologies for late reply !

15/07/06, Noel J. Bergman <noel (AT) devtech (DOT) comwrote:
- Have a separate "messages", consisting of [key, blob]

yep.

- The blob (or clob, as appropriate) should be the last column of any
record.

While this is enough for Derby other DB's gain more performance tuning
flexibility if the CLB is in a joined table with only two columns,
CLB and PK. I understand from our DBA's that can choose to
save CLBS to file and not use the DB storage if we do this. I gather
that this is better for very big CLBS, like perhaps an email with a
BIG attachement.

d.

To unsubscribe, e-mail: server-dev-unsubscribe (AT) james (DOT) apache.org
For additional commands, e-mail: server-dev-help (AT) james (DOT) apache.org