geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [JavaMail] re-engineering of JavaMail from specs?
Date Tue, 12 Aug 2003 19:41:30 GMT
>> So, in order to meet the specs, which should I follow? Should I 
>> provide
>> all public  methods listed in the API documentation, or just those 
>> that
>> are directly mentioned in the PDF? My fear is that if I do the latter,
>> then we'll end up failing the TCK since it won't have all the methods
>> the TCK is expecting.
> Although I still have *huge* reservations about the quantity of work 
> you are
> taking on, and how worthwhile it will actually turn out to be, I'm 
> afraid
> that think you have to do both or nothing. You'll have to abide by 
> both the
> javadocs and the descriptive specification.
> Anyone using your clone of javaMail will expect it to honour Sun's
> documentation in *exactly* the way they would the published API.

Yes, but the question I have is whether I can legally read Sun's API 
and then write an implementation of it. I'm not going to touch the 
source code, but there isn't any way of creating a JavaMail 
implementation using the PDF Spec alone; it simply doesn't provide 
enough code.

I was also working on it in stages; first, get the abstract 
classes/interfaces together for the API, and then work on the 
implementation for validation etc, sending mail. As I mentioned 
previously, I have some mail implementation classes kicking around from 
before so I have something to work with -- alternatively, there's some 
stuff in the JAMES implementation which may work.

> IMO anything else is deviating from the API spec, and probably ought 
> to be
> discussed and agreed first.

I agree completely -- the JavaMail has some glitches, but needs to be 
there 'warts and all'. I've been thinking what I like/don't like in the 
API, and have been coming to the conclusion that either JavaMail can 
sit on the AlexMailAPI, or vice versa. (The advantage of the latter 
means that it should be portable to other servers as well.)

But at a first cut, I was looking at JavaMail in itself, without any 
extensions to that API.

> After all there is still some lack of clarity about how far this 
> project is
> about creating a "pure" implementation and how much it is open to
> enhancements, and that's just with regard to implementations and the 
> "clean
> room" re-creation of interfaces, never mind what you are proposing, 
> which is
> a fully blown re-creation of existing API classes, without (because I
> believe it is expressly prohbited by the licence) reverse engineering 
> or
> reference to the source code.

This is my problem; how can I implement the JavaMail API in a way that 
is legally acceptable by the ASF? Is taking the signatures from the API 
documentation legally the right way to go? Otherwise I don't see how 
this would be possible.

Obviously, I'm not using reverse engineering or using the source to do 
the implementation; on the other hand, I'm also not bothering with 
JavaDoc since I'm assuming that people know how to use it and it's just 
the implementation that's required :-)

I also belive that whilst they are documented, the com.sun 
implementations do not form part of the API and therefore shouldn't be 
cloned. I don't know if that's a right decision or not.


View raw message