geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <>
Subject RE: [JavaMail] Re: Geronimo standard Sun-API jars
Date Fri, 08 Aug 2003 22:18:04 GMT

> > The problem is that there is a lot of code related to Mime parsing and
> > Address validation needed to conform to the RFC's in javaMail, there
> > are a
> > lot of mail RFC's ( and they would
> > require a lot of work to re-implement.
> They aren't a requirement of JavaMail; they are a requirement of
> SMTP/MIME and related RFCs. It just so happens that JavaMail also uses
> them.

I hope you're not seriously suggesting that it would be possible, never mind
whether or not it is a good idea, to create a mail application which doesn't
conform to the relevant RFC's.

If my criteria for cloning javaMail is that that action must offer some real
benefit, it would be seriously negated by failure to conform to the relevant
RFC's. Part of the value of javaMail is the extensive work done in support
of conformance.

I'm *not* talking about the reference implementation of providers in the
com.sun.* packages, thats obviously a target for this effort, what I'm
talking about here is are the abstract and concrete classes in the
javax.mail.* packages, these are part of Suns API and it is not strictly
required that an implementation re-create them. In fact the original reason
mooted for doing so was simply to make them available under the ASFL. This
is perhaps a worthwhile sentiment as far as the j2ee API's which are mainly
interfaces are concerned, but javax.mail is mainly implementation, and
implementation of a lot of unattractive RFC conformance to boot.

> > I'd be very wary about starting down the road of an Apache clone of
> > javaMail
> > unless it really offers serious advantages.
> o Easier API to use to generate/send mails
> o Less global configuration settings (JavaMail uses global system
> properties)
> o Conformant JavaBeans representation of MimeMessage
> o Use of Mail.getAttachment() to facilitate attachments, rather than
> presenting the low-level layer of how they are transmitted in MIME
> Multipart formats

I don't believe that cloning javaMail would give anyone much opportunity to
add functionality to the API, we're simply talking about cloning it not
extending it.

Any ASF clone of javax.mail would have to be a direct replacement for the
original, if you want to implement extended functionality in order to better
manage internal handling of the objects surely the normal use of inheritance
and polymorphism is sufficient?

It isn't possible for *us* to extend the specification either, we're not

> > Bearing in mind that any clone of javaMail would have to offer pretty
> > much
> > interchangeable behaviour with the official product, particularly if
> > it has
> > to pass tests, the issue of implementing the Store and Transport
> > interfaces
> > is where we should start, and quite probably end too.
> I've got an implementation of Transport kicking around from before that
> I can donate to the project, and I'm more than willing to give an
> implementation of JavaMail ago. But since I don't have access to the
> CVS repositories for dumping implementations, I'll have to send it as a
> pretty big patch file :-)

Well hold on until things settle down, it all seems a bit up in the air here
at the moment :-)


View raw message