james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: JavaMail API and SMTP transport for Geronimo
Date Wed, 26 Jan 2005 19:18:58 GMT
Danny Angus wrote:
> Jeremy,
>>One problem I have is that the spec and API doc are not always clear
>>about what should be done - e.g. from the JavaDoc for
>>"The current implementation checks many, but not all, syntax rules."
>>It would be nice to know what was supposed to be checked and what wasn't.
> This would initially depend upon what specific version of the RFC is
> supported,  but also they may not support all of the rules, for
> example there are a load of paragraphs in some RFC's which specifiy
> special rules for military things (time format is one). Sun may have
> taken the view that things like this are not necessary.
> In this case you need to decide what it is you want, 100% RFC
> compliance, a do-or-die TCK pass, or a pragmatic set of useful
> validations.
> James already have some address validation which is stronger than
> Sun's, the problem would come if the TCK has specific test cases which
> are ambiguous, for instance they may be expected to pass Suns
> pragmatic validation yet fail more rigorous validation and v.v.
> For an example the RFC's say that the domain part of an address is not
> case sensitive but the username part is. Almost no one enforces this
> (in James its optional). The question is does the TCK enforce it?

This is the really annoying thing in the Spec/API JavaDoc - there are 
certain areas which are just plain ambiguous. Hopefully having the TCK 
will clear up some of these up.

>>For Geronimo we can cut back on this a little - the J2EE specification
>>only requires that we provide a transport that supports addresses of
>>type InternetAddress and messages of type MimeMessage; we do not need to
>>support any store protocols.
> If you only have to provide implementations, in effect implement the
> same functions as Suns reference implementation and not duplicate the
> API then I'm think this is achievable. If you have to recreate the API
> as well I think you have a significant obstacle, in fact it may well
> be easier to sort out the legal issue.

We've been working the legal issues for a while - I still hope they can 
get resolved but with the status quo it is believed that we cannot 
distribute Sun's code with Geronimo and yet we are required by J2EE to 
distrbute both the API and a transport implementation.

> An SMTP transport is one thing we'd love to have, Suns RI doesn't fire
> any events and James could make good use of events raised by
> Transport.


>>However, for this to be of general use I agree that we should provide
>>good implementations of as many of these as we can.
> I fear that implementing any of the javax.mail stuff will suck us down
> a pit we can only get out of by recreating the whole thing. And sadly
> as Sun, in their wisdom, have made their API out of classes not
> interfaces this is not trivial.
> To implement the bits the API expects us to implement is more reasonable.

Unfortunately we have to do it all (unless the legal issues get resolved).

>>Knowledge and expertise alone will help a lot.
> We'll I can't offer a lot of effort but what knowledge I have is yours.
> One question I have is this, do you envisage this as being geronimo
> code, or would you consider collaborating on an effort in James?

In Geronimo we have a specs module where we provide Apache licensed 
versions of all the spec APIs we need to distribute with the server - 
these are the actual API classes/interfaces, not implementations.

We would be quite happy to move the APIs for JavaMail and/or JAF to 
James - or, as some have proposed, to a separate spec-api project.

I'd say we have no desire to provide implementations of those APIs and 
would love to collaborate with James.

> d.
> P.S. Should we take this to the geronimo lists or keep it here?

I'd say keep it here as most people in Geronimo land just want the 
redistribution problem to go away. I'll post a message there though 
pointing to this thread.

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

View raw message