james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: JAMES ... now that we (may be) merged, where to?
Date Wed, 04 May 2005 17:18:58 GMT
> POJO is not high priority for me too.


My priorities are:
> 1- Full DSN support (SMTPServer, Delivery Mailets/Processor, MailImpl)


I assume that you're aware of the existing level of support for DSN, right?
You just want to improve it.

> 2- RemoteDelivery: reuse/sort connections to the same hosts (mass

+1 ... HOWEVER, that must be tunable.  Perhaps we'll want subclasses for the
actual delivery engine.

> 3- RemoteDelivery: better error handling based on specific ESMTP / DSN
>    reply codes.

+1.  Mind you, JavaMail isn't the most helpful thing on the planet in this
regard.  I wrote most of the error detection code to pick up what we were
getting back, and it is admittedly a hack.

> 4- Spooler: improve match/mailet speed and movement between processors.

Sure.  And a better spooler.

Unrelated for the moment, but does JMS support a JDBC transport?  I would
like to see us able to store messages in a database on a cluster, and not
have to actually send the messages around.

Also, I'd like to see us make use of Derby out of the box.  That way, we can
count on JDBC support in all cases.  People can then switch to MySQL,
Oracle, DB2, or what-have-you, but we can always count on JDBC for
functionality.  Derby recently added support for network clients, so we can
eventually use that, too.

> 5- S/MIME: new Mailets to check signature, encrypt/decrypt and more.

Uh, we already have those.  Have had them for years, now, predating Domain

> Most of my priorities will not require a 3.x change (backward
> can be mantained).

I feel that we can call the new trunk v3, and move forward with it.  And
folks who want JAMES running on Loom ought to be able to use that same code,
just as Stephen McConnell should now be able to get this running with

> Jdk1.4, POJO, Mailet API refactoring and this kind of changes will
> instead require a 3.x branch.

Probably multiple branches over time.  For example, Jason and others can
spin off an IMAP branch, work on IMAP there, and then merge back when ready.
Branching is much nicer with SVN than CVS.

	--- Noel

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

View raw message