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 12:42:42 GMT
On Tuesday, Aug 19, 2003, at 12:19 Europe/London, Danny Angus wrote:

> Alex,
>
> I'd rather keep this discussion on the list, and with your permission 
> I'll
> FW this reply..

Don't have a problem if you do, but I feel that the majority of the 
list are unlikely to want to wade down through this in any more detail. 
Some of the PMC might, though.

>> Possibly, but the JavaMail specs don't actually change that much. And
>> any such changes that do fall behind would be picked up by the TCK for
>> the next flavour, wouldn't they? For example, there was one new method
>> (setSender()) added in the most recent version of the JavaMail API.
>
> Yeah, and if we used Sun's API it would be no problem, if we don't then
> *someone* does indeed still have to update our version of the API.

Agreed.

>> Hopefully I said that I was going to do this in 3 stages, and I'm only
>> at the end of stage 1 at the moment. But it is planned to continue
>> along that path, and therefore the work I have done so far is to work
>> towards that end goal.
>
> I understand, but I don't want to see you wasting your time.

That's OK, it's a personal challenge more than anything else. And if 
Apache don't want the source, I can still make it available under an 
open-source license myself that isn't the LGPL (issues of which still 
arise in the Java land...)

>> You say that 'you believe this is complex and nasty' -- I don't think
>> it's as nasty and complex as you do. To be honest, the actual answer 
>> is
>> likely to lie somewhere between the two viewpoints.
>
> Fair enough. I've actually written Mime parsers before, but not in 
> Java.
> However the javaMail parser effort is compounded by the fact that you 
> *also*
> have to conform to the API spec which means that you have to somehow 
> do this
> using all the same classes and methods that Sun have used.

True. I didn't say it was going to be easy, either :-) TBH it would be 
useful if you could provide input on MIME parsing, if you've got any 
source available on that.

I climbed Ben Nevis once (highest mountain in the UK). It was covered 
with fog/cloud (we started early) and the mountain disappeared into the 
cloud. We were pretty sure that the mountain ended at the cloud level, 
so we kept climbing, and every now and again it would plateau off. Just 
as we thought we were getting to the top, we went round a bend and 
there would be another stretch of mountain, going up into the clouds.

I would never have climbed Ben Nevis if I could have seen all of it 
when I started. However, I could climb it thinking that the end was 
round the corner, and indeed, when I got there I found I had more to 
do. But in this way, I did get to the top of the mountain. [Getting 
down was another story ...]

>> Yes, I agree, but they are most unlikely to do that.
>
> Not necesarily, Apache has some clout when it comes to making our voice
> heard with Sun.

Good. Let's see what happens, and as such time as the legal situation 
is clarified and we can use their binary code, we can swap out what 
I've done with theirs.

>>> As it stands Sun's Mime parsers and related classes form part of the
>>> API,
>>> they are not interchangeable components like the Transport and Store
>>> mechanisms are.
>>
>> Yes, they are. And they will require some work to implement correctly,
>> but (hopefully) not insurmountable.
>
> Not implement, copy.

No, not copy. A copy is an exact replica. What we want is something 
that does the same. And I used the term 'implement' to mean 'does the 
same'.

>>> What I meant was that as the specifications (RFC's and the API's)
>>> evolve
>>> with time it will always be necessary for someone to be aware of 
>>> these
>>> changes and "copy" them into geronimo's JavaMail clone.
>>
>> Yes, this is indeed the case. However, if Geronimo (or whatever) 
>> passes
>> the TCK then it will by inclusion pass the JavaMail stuff. Any 
>> failures
>> can be easily noted and brought up.
>
> But why expend this effort when we could use the API as it is intended 
> to be
> used??

Because legally, we don't know we can.

> Also IIRC the TCK's test the conformance of implementations, not of the
> API's themselves.

Well, they have to test the conformance of an implementation, just use 
the implementation that we give (that is based on the APIs). The 
purpose of the TCK is to make sure that everything it tests behaves in 
a way consistent with the JavaDoc/specs. If the TCK doesn't test 
feature X (like the comparison of two URLName's protocols/schemas) then 
that may be ambiguous and there could be different reference 
implementations.

>>> Which is a valid reson for you to do this, and I respect that.
>>> What I am concerned with is that I haven't seen a valid reason to
>>> place this
>>> burden on Geronimo, not one that also takes account of the particular
>>> concerns I have.
>>
>> Actually, I started doing this with the goal of then moving it later 
>> to
>> a commons- package, but developing it in the incubation of Geronimo
>> because (a) I wanted to get involved with more than just the JavaMail,
>> and (b) because I'm not an ASF committer and thus don't have many
>> priviledges at the moment :-)
>
> But basically it is a personal decision, and not something which has 
> been
> agreed upon by either the geronimo comitters or the incubator PMC.

In the initial phases of this project, there were calls for volunteers 
for different topics. I suggested JavaMail, proposed some discussions 
about whether to re-implement the API or reuse it, and asked for legal 
advice. No further legal analysis has been reported on here (yet), and 
in order to do the implementation of JavaMail you need to have the API 
available.

So it is a PMC decision that hasn't been answered on the legality of 
reusing the JavaMail mailapi-jar file yet, and in  the absence of that 
I am taking the only course towards making JavaMail available.

>> As for whether it should be part of Geronimo; the J2EE server must 
>> have
>> Transport/Stores provided, and I intend to do those later.
>
> Yes, thats the implementation, I'm only concerned with the API.

Acknowledged.

>>> If I was sure that a majority of the comiters were aware of the
>>> issues, and
>>> hand taken a properly mandated decison to continue with this, then
>>> fine.
>>> However I have a feeling that thay aren't aware and haven't actually
>>> mandated this.
>>
>> I'm not sure where 'mandated' comes in to it.
>
> This is an ASF project, not sourceforge, it has rules and processes 
> which
> must be complied with, one of which is that the project must comply 
> with its
> charter, another of which is that there should be oversight by the PMC 
> and
> not a free-for-all.

Fair enough. I've not worked on sourceforge either, and this is my 
first run into ASF as well.

I attempted to make my concerns loudly at the start of this 
implementation run and it hasn't been resolved yet.

> I don't believe that copying the javaMail API is mentioned, nor that 
> it was
> necessarily intended by the proposal, it hasn't been explicitly 
> sanctioned
> by the comitters or the PMC.
> I think that, given the issues I've raised, there should be a debate 
> about
> the issues and a decision made.

In order to do this, we need to know from a firm footing what the legal 
position currently is, and from that decide what the right way forward 
is.

> If contributors to the James project wanted to copy javaMail there 
> would
> have to be a proposal, a debate and a vote, and even then we might 
> have to
> justify to the Board why it was acceptable under the charter.

James isn't in the incubator though. Geronimo is. My understanding of 
the difference is that ideas can be tried, and then removed 
subsequently (or even replaced with the Sun API).

> Seems to me that the same thing should apply here.

Quite possibly. PMC people, what's your say in this? How do we resolve 
(a) the legal issues, and then (b) what step(s) are necessary to get 
the decision ratified?

>> I don't know the
>> licensing/redistribution issues associated with the JavaMail API (as
>> opposed to the implementation) are actually compatible with Geronimo's
>> goals. There's been some debate about not using LGPL stuff in 
>> Geronimo,
>> for example. In any case, my purpose was to provide an implementation
>
> Which is *fine* but you are actually providing a copy of the API which 
> may
> be much less fine..

No, I am not copying the API. I am implementing it from JavaDoc and 
from the spec. I have not used any reference to either the RI or the 
source code in order to do it. I am fully complying to the extent that 
I am aware from the JavaMail-spec-license which declares that it is 
allowable to provide a clean-room implementation of the APIs provided 
that no source or binary reference to the RI is allowable.

>> and then let the community decide (as opposed to just the committers)
>> what to do with it.
>
> .. particularly if you are not prepared to stick around and maintain 
> it.

... then it can just be deleted. Or someone else can maintain it. Or 
legal issues can be resolved with Sun to allow (re)distribution of the 
mailapi.jar. Or we can have a J2EE server without mail support and fail 
the TCK. Or ...

If I am the only person actually interested in this JavaMail API then 
it is clearly a bad thing if I go elsewhere/don't come back. And I had 
hoped that there would be a little more support for wanting the 
JavaMail APIs in the James group (hence the original cross-posting of 
the announcement), or indeed for other Apache projects (maven, ant, 
turbine) that may require the use of JavaMail.

Having an ASF JavaMail API (and implementation) would allow that, and 
if it were going to be cross-used, then a migration to commons-javamail 
(or similar) would make eventual sense. And if many projects were to 
use the commons-javamail (especially if some of them -- like Geronimo 
-- were using it and running against the TCK) then there would be a lot 
more reason to keep it up.

>>> The Transports and Stores and other classes distributed in the
>>> "com.sun"
>>> packages are Sun's "refrence implementation" of the API,
>
>> I think the term 'reference implementation' can be misused as well.
>
> Not really, it is used to describe the implementation produced and 
> approved
> by Sun of an API which is intended to be used as a benchmark to 
> demonstrate
> how an implementation of the API should function.

No. The JavaMail Reference Implementation is their implementation of 
both the com.sun mail transports/stores, and also the implementation of 
the API. They have not released a seperate JavaMail API and JavaMail 
implementation; it is all one bundle. Granted, within the bundle they 
have different Jars, but the entire thing is referred to as the 
JavaMail Reference Implementation, or even more incorrectly, the 
JavaMail API.


>> I meant my replacement to be both the API and an implementation of
>> Store/transport as appropriate.
>
> Yep I know, but why copy the API?

Because in my inexpert legal opinion, Apache does not have the right to 
re-re-distribute mailapi.jar or mail.jar from the JavaMail Reference 
Implementation/API package. Thus we can provide a program that contains 
mailapi.jar, but we can't allow others to redistribute the geronimo 
package. Immediately, therefore, we can't have mailapi.jar in the 
Geronimo codebase and for that codebase to be handled by mirrors around 
the world.

>>> Anything which was capable of being used wholly in place of the API
>>> would be
>>> an alternative API, not an implementation.
>>
>> Correct, and I'm not proposing to do this.
>
> But you *ARE* doing it, I'm watching you do it.

No, it's the same API conforming to the same interface. Perhaps it's my 
mis-interpretation of your 'alternative API' or 'wholly in place of the 
API'.

I'm implementing the javax.mail package as described by 
http://java.sun.com/products/javamail/ as the specs/javamail module. 
Nothing more, nothing less.

>>> Are we not therfore creating an alternative when we should actually 
>>> be
>>> creating an implementation?
>>
>> No, we are creating a clone of the API and an implementation of the
>> API. Licensing issues surrounding the API itself are unclear, whereas 
>> a
>> clean-room implementation of them is clearer.
>
> Yes and who has decided that it is worth hosting and maintaining a 
> project
> to do this for javaMail, simply in order to redistirbute it under the 
> ASFL?

1. Geronimo must have a JavaMail component to satisfy the J2EE TCK.
2. It has been mandated that Geronimo will pass the 1.4 J2EE TCK.
3. It is not (IMNSHO/IANAL) possible to redistribute the mailapi.jar 
file
4. In the absence of redistributing the mailapi.jar file, an 
alternative must be found.

>> There seemed to be issues as to whether even having the JavaMail in 
>> the
>> distribution were possible; the alternative being to force the user to
>> download it from Sun.
>
> Which James does, believe me it is not a barrier, though I admit it 
> may be a
> slight inconvenience.

And there is no-one on the James team who would think an ASFL JavaMail 
would be a good thing?

>> Maintenance is likely (IMNSHO) to be a trivial issue and once built,
>> only deltas in the spec will need to be applied. Hopefully others will
>> be sufficiently interested (e.g. in the James camp, or if it migrates
>> into commons-javamail) to perform those changes as and when. It may 
>> not
>> be the original Geronimo people that do this.
>
> But why would anyone bother to maintain this when Sun's original 
> version of
> the API is available?

You would only do this if the API is unavailalbe. My inexpert legal 
readings indicate that it is. Similarly, James does not redistribute it 
because you are not allowed to.

>>> After all Sun's API is released under a licence open *enough* for
>>> James to
>>> use it and not bother maintaining a duplicate of this functionality.
>>
>> Is it, though? My understanding of the API license is that you can't 
>> do
>> it in an ASF-compatible license (for the reasons that James doesn't
>> ship with the API).
>
> James doesn't ship source with javaMail coreect,  james binaries can 
> and are
> shipped with javaMail.

Is this in the letter of the license, though? Do you have the right to 
distribute it, and allow others to redistribute that?

>>>> I have heard that the ASF are in talks with Sun regarding licensing
>>>> their
>>>> JavaMail implementation through an open-source license.
>>>
>>> Whatever. Thats about the implementation, the "com.sun" things, not
>>> the API,
>>> the "javax.mail" things.
>>
>> I don't know what the talks are; it just lists them on the apache
>> websites :-)
>
> You yourself say "licensing their JavaMail implementation" this is
> _by_definition_ the RI not the API.

Sun uses the term "JavaMail API" to mean their reference 
implementation. The javax.mail API are only downloadable through their 
Reference Implementation.

>>> Yes, but what I have a probelm with is not your implementation, but
>>> the need
>>> for creating a whole replacement API, and where the resources will
>>> come from
>>> to maintain it once your enthusiasm wanes.
>>
>> If it comes to a stage where the API implementation (as opposed to the
>> transport/store implementation) is becoming delapidated, then no doubt
>> it will be something that can be junked then. At least in the 
>> meantime,
>> we have an open-source (in the sense of freely redistributable) API
>> that we can use to build the transports/stores.
>
> I don't think that is the Apache Way, I've been led to understand that 
> the
> most important thing is community, that products should be maintained 
> by
> self-sustaining communities.

Agreed. And hopefully, this will become one for the whole J2EE space.

Ideally, this would also happen for the JavaMail as well, but although 
some other patches have been made to the specs/javamail (and activation 
package, on which it depends) I have done the bulk of the initial work. 
But that's not to say in the future it won't develop, and everything 
has to start somewhere. Killing off a product because within a week it 
has not got a full community behind it is a bit of overkill IMNSHO ...

> The incubator exists to build such communities, geronimo is being 
> incubated.
> My problem is that your copy of javaMail isn't a project being 
> incubated, no
> one has taken any decision that it should be pursued and I feel quite
> strongly that it may be more of a liability to geronimo than an asset 
> in the
> longer term.

It's part of the goal of Geronimo, though. Geronimo provides a J2EE 
server, that server needs a mail stack, and that's what I'm working 
towards.

It's good that you're raising concerns about the long-term life of 
JavaMail here. Hopefully others (if they are still reading this by now 
:-) will realise that it's not just me, and that everyone can make it 
better.

It's also good that you're explicitly bringing this to the attention of 
the PMC. Hopefully a decision will not be far off.

> Alex.


Mime
View raw message