geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [JavaMail] concerns
Date Tue, 19 Aug 2003 08:52:22 GMT
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.


Mime
View raw message