On Tuesday, Aug 19, 2003, at 08:38 Europe/London, Danny Angus wrote:
Richard,
I also believe that it behooves Geronimo to have its own implementation
because it gives us the option of going beyond the spec to impl
value-add-ons.
You seem to be falling into the same trap, it is possible to create an
IMPLEMENTATION of the API, to replace Sun's RI, without re-creating the API
itself.
We can add value without re-creating the API, and in fact if we pursue the
goal of recreating the API we can't add value through that process.
Some things that are worth bringing up here:
Classes in the javax.mail package represent the 'API' of JavaMail; implementations live in other packages (e.g. org.apache.geronimo.mail) separate from the API (aka mail providers).
I believe that Danny's main point was that he doesn't see recreating the API as an important part, as opposed to creating the mail providers. However, this is on my to-do list (see the ApacheJ2EE/TO-DO in which I list the stages of the JavaMail development) as the final stage of JavaMail implementation. I suspect that Danny sees this as more important (and especially if Sun provide an implementation of JavaMail, whether binary or source) for use in Apache (though at this time, the conversation with Sun is still ongoing and appears to only cover binary use).
I also believe that Danny has some unsatisfied concerns regarding the difficulty of implementing the JavaMail APIs. He is concerned that a number of RFCs exist which control mail, and that he is concerned that not all of these will be implemented to the standards that the JavaMail Sun RI gives.
Actually, there isn't so much to be concerned about, since mostly the RI classes force specific types of RFC down your throat anyway, such as the MimeBodyPart class. Additionally, some of the other classes use Sun java.net classes to perform RFC validation of certain aspects. And lastly, looking at the documentation for classes like 'InternetHeaders', it actually places the burden on the caller of providing the information in the right format (i.e. US-ASCII) rather than the implementation itself.
Also, there isn't /that/ much left unimplemented in the API yet. There's only about 100 methods to go (which equates to one method per class), and two of the packages in the API have been implemented fully already.
He's right that the implementation of the providers/store hasn't been started yet, but since I'm working towards that he can rest easy :-)
Alex.
