james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <Danny_An...@slc.co.uk>
Subject Re: what competition is doing
Date Tue, 03 May 2005 16:04:14 GMT
Andy,
      a. email.apache.org/james
      b. email.apache.org/mailet (associated lists)

As Noel said it would be James/server & James/mailet, but no problems here
with making the separation as obvious as we can, and see where we go.

I'd actually like to see a clear distinction between:
Mailet - the API;
Mailets - some "provided" Mailets that do real stuff;
A container Reference implementation & TCK?;
James - product embedding the container RI and provided mailets


> 2. Discuss the overlying contract for Mailet containers.
> 3. Creation of a specification similar to EJBs which lets mail container
> folks know what the "should" "shouldn't" "shall not"s are.

I thought a lot about this a while ago, and would love to revisit it.
I think the James "merge" should finish first, then we can start by
identifying the bits that are obviously missing first.

> 4. Creation of a JUnit set which tests compatibility of mailet
> containers.  A TCK if you will.
> 5. Require TCK to dictate API to dictate Spec

See my response to the first point. This is a fine ambition,
and because Mailet is small its probably achievable.


> 6. Develop two (initial) branches "propose" and "mailet-2.0".  Nothing
> makes it into "mailet-2.0" unless

Unless what Andy? I guess we're talking about a review process.

>I would also like to completely reimplement and rethink JavaMail

Yeah. Big job, little reward. We need a production quality implementation,
but I'd be wary of giong down the "total rewrite" route that some others
have
proposed in the past.

>  I'd rather like to collaborate if you guys have the same issues.
> Benchmarking of JavaMail has not been very promising and
> I find its API rather limiting and bizzarre.

Yeah. The total focus on it being a client library makes it an odd thing to
use. But the well tested
standards compliant code in some of the API classes are a rich resource
worth hanging on to.

d.


***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you
are not the intended recipient (or responsible for delivery of the message to the intended
recipient) please notify us immediately on 0141 306 2050 and delete the message from your
computer. You may not copy or forward it or use or disclose its contents to any other person.
As Internet communications are capable of data corruption Student Loans Company Limited does
not accept any  responsibility for changes made to this message after it was sent. For this
reason it may be inappropriate to rely on advice or opinions contained in an e-mail without
obtaining written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to scan attachments
(if any). Opinions and views expressed in this e-mail are those of the sender and may not
reflect the opinions and views of The Student Loans Company Limited.

This footnote also confirms that this email message has been swept for the presence of computer
viruses.

**************************************************************************

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


Mime
View raw message