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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
