geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject Re: [JavaMail] re-engineering of JavaMail from specs?
Date Tue, 12 Aug 2003 22:04:04 GMT
Alex,

(BTW are you in Europe?)

> 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.

Well if others have typed in interfaces from the javadocs and not been "gone
after" I'd suggest that reading the javadocs is OK.
In addition it would be pretty much 100% impossible otherwise.
Read the licence and pay attention to the no reverse engineering bits..
At the end of the day if you're really worried someone can ask the Board to
get legal opinion.


> I was also working on it in stages; first, get the abstract
> classes/interfaces together for the API,

Don't forget that it's with JavaMail theres also concrete classes, like the
oft mentioned MimeMessage, which are part of the API too.
Everything in javax.mail.* is part of 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.

Not so's you'd notice ;-)

> > 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.)

Vice-versa is pretty much what I've been trying to get across.

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

It'd be a hell of a lot of work, but if you do it properly I'm sure an ASFL
version of javaMail would be popular.

> 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.

Yeah, agreed, I guess we ought to get some claification, have you read the
licence recently? does it give you any hints?

> 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 :-)

Right, the trouble is that for a re-creation of javaMail to make any sense
it has to be a runtime replacement for javax.mail.*
Therefore it has to duplicate every single class and method sig. exactly.
And you can't ever depend upon any classes in Sun's distribution because
that'd re-introduce precisely the licence dependance you are trying to
avoid.

> 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.

Yes, the com.sun classes are the Reference Implementation (RI) of the
interfaces and abstract classes which are intended to be implemented by
implementations ;-) . the javax.mail ones are not. The scope of this project
(and to some extent of James) *is* the com.sun classes, javax.mail is not in
the scope of James and may not even be within the scope of this effort.

d.



Mime
View raw message