geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <>
Subject RE: [JavaMail] concerns
Date Tue, 19 Aug 2003 09:33:09 GMT
Alex wrote:

> >From where, though? I had volunteered to do it, and worked away at
> providing the implementation. From a community PoV, the files haven't been
> in there very long but no doubt others will pick it up where it needs to
> be handled.

This is not a given. Geronimo is a new project, there is great scope for new
code ending up being orphaned if a community of interested people doesn't
gel around it, there is no guarantee that this will happen.

I want to emphasise that this is not intended to be
> criticism of
> > him in any way.
> Not taken as such, don't worry :-) I have a fairly thick skin (along with
> a fairly thick body and a fairly thick skull)

Nice one. :-)

> However, one of the reasons it took me a long time to do in the
> first place is that I didn't /just/ do the APIs -- I also implemented
> (where possible) the methods that go with it.

I think its important to clarify something here, if the method is a real
method in Sun's API, not an interface method signature or an abstract
method, then you *must* implement it or you haven't cloned the API.

I'm sure you know this already, my "issue" is that there is a lot of this
needed, and just making a first pass isn't (no disrespect) going to
create anything that is worth having instead of Sun's API.

>Gut feeling is that I've got
> between 60% and 80% of the base implementation of the JavaMail API done.
> (Key things missing are the MimeMessage and Folder methods, though some
> are done).

I really suspect that once you start into MimeMessage et-al you'll discover
why Sun make this pert of the API and not simply an interface.
I believe it is because the job (of conforming to the Mime RFC's) is complex
and nasty and easily tested.

Now I have some reservations about Sun's version from the API, but I believe
that the way to solve that ought to be by Sun refactoring the implementation
out of the API and into the RI.

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.

> For maintenance purposes, I am developing a set of JUnit tests which will
> hopefully avoid the need (or difficulty) of too much maintenance.

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.

> To a greater extent (and certainly initially) this is true. But once the
> core bits are done, it will be easier to maintain. Some of the RFCs are
> implemented as Sun classes in 1.4 anyway

Yep, I know, and if you look at it that way many more RFC's are implemented
in the existing JavaMail API, not Sun's refrence implementation of the API,
but the API itself.

> >From a personal PoV, I've used JavaMail before and have had experience
> with using it. I thought it might be fun to work on as an initial task
> working with Geronimo. And it's better than writing up my thesis :-)

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.

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.

> Yes, this is indeed the case. In fact, the only parts where we could
> differ would be in the implementation of the actual transport/stores
> anyway, since the API is firmly fixed in how its supposed to behave.

Yes, this is again a point which I feel is being confused.
The Transports and Stores and other classes distributed in the "com.sun"
packages are Sun's "refrence implementation" of the API, these are fully
within the scope of this project and offer an opportunity to add value and
functionality within the specification of the API.

The rest of the classes, those in the "javax.mail" packages ARE The API,
they are not an implementation of the API they are it and it is them,

> The J2EE 1.4 spec mandates a JavaMail implementation of some kind;
> whether this be based on the Sun RI or another open-source one is still

Ok, I understand. But someone answer this..

An implementation of the API would depend upon the API code, and would
replcae the "com.sun" refrence implementation.
Anything which was capable of being used wholly in place of the API would be
an alternative API, not an implementation.

Are we not therfore creating an alternative when we should actually be
creating an implementation?

> o To provide JavaMail integration with Geronimo without dependency on
>   Sun's JavaMail (Mainly for licensing reasons)

I understand this, but don't believe that this alone is worth the effort
needed to create and maintain this code.

> o To provide an Apache implementation of the mail store/transport
>   protocols

This *IS* an implementation and I agree this *SHOULD* be the focus of the
javaMail effort.

> o Subsequently to make the same version available as part of the
>   jakarta-commons packages, for possible integration into other Apache
>   products like JAMES

This is only likely to happen if there is some demand for it, something
which I am not convinced of.
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.

Think re-use.

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

> Should this come
> about, then clearly the work I will have done implementing the APIs will
> become obsolete and the correct decision will be to replace them with
> Sun's implementation.

Actually if that happens it will be _Apache's_ implementation, like Tomcat
is Apache's implementation of Servlet & JSP.
Apache doesn't maintain the servlet and jsp API's, nor AFAIK an ASFL clone
of these API's.

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.

> As yet, however, I don't know what stage this is at,
> so feel that it is worth gambling to make it available now and for the
> initial, if not subsequent, releases of Geronimo.

Make the *implementation* availabe, yes thats a Good Thing, whatever
But to replicate the API for the sake of the licence alone is another matter

> It has also given me opportunity to work with ASF; something which I've
> not done before and it's been pretty enjoyable :-)

Good, I'm glad about that, it's a good place to be, don't let my politiking
put you off. :-)


View raw message