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:51:12 GMT
Alex, Richard, everybody..

> I believe that Danny's main point was that he doesn't see recreating
> the API as an important part,

Actually I see it as being a risk, and an unecessary one, there is a lot of
work involved to conform to RFC's.
Sun has done a lot of this work and it form part of the API.
Why would geronimo releases risk being blocked by this when it doesn't
really need to be done at all?

_Why_would replicating javaMail be within the scope of Geronimo?

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

IMO this is the *ONLY* part which turly represents implementation of the
API, as compared to creating an alternative version of the API.

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

Clearly this would not be a case of Sun providing the API, merely the
refrence implementation.
I stress I am fully in favour of seeing an implementation created.
I am opposed to the work involved in the creation and maintenance of an
alternative version of the API unless the whole community reaches some form
of understanding of the issues and some agreement. Is this not the Apache

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

Wrong, I am *NOT* talking about the RI.
I am addressing the API, which itself provides conformance with a number of

My concern is that as this work has been done and forms part of the API, it
is *NOT* part of the RI it *IS* part of the API, the geronimo project is
unnecessarily opening itself up to a whole lot of other specifications which
must be complied with.

My basic questions are; Will someone tell me why we should consider doing
this, what is the benefit?
Is it simply the ASFL?
Is this therfore worthwhile?

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

MimeBodyPart is an API class.
Any implementation can leave RFC confomrance of this class to be the concern
of the API.
If, however, we insist upon creating an alternative version of the API that
concern becomes ours.

> Additionally, some of the other classes use Sun
> 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.

Theres more to this than that, but I don't think this is the right place to
be discussing the detail and interpretation of mail RFC's.

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

I'm not conerned about that, there's plenty of time, I am much more
concerned that your current work is creating a white elephant.


View raw message