On Friday, Aug 8, 2003, at 23:18 Europe/London, Danny Angus wrote:
Alex,
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 (http://james.apache.org/rfclist.html) 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.
No, the original mail message suggested that there were a lot of RFCs implemented in JavaMail and seemed to suggest that they were specific to JavaMail. I failed to say concisely that the RFCs were not just JavaMail, they were generic mail RFCs that should be in other implementations whatever flavour of mail API it was.
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.
Part of the JavaMail implementation conforms to the RFCs, yes, but that doesn't specifically negate having other implementations that also conform to the RFCs.
... 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.
The APIs don't, in themselves, provide the conformance. The implementation (com.sun...) packages provide the conformance/validation.
In any case, the API for JavaMail tends to be bogged down with low-level representations (such as MimeBodyPart) when it could present a more unified interface such as getAttachment(). IMHO the JavaMail provides a low-level representation, which is less useful for developers wanting to send/receive mail.
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.
I was talking about an extended Mail API set, that provided a JavaMail API to allow legacy systems to use it as well. Having had problems with JavaMail (as above) I wanted to try and create an implementation to address some of those issues.
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?
In the case of polymorphism, not really. Part of the problems with JavaMail are the non-trivial use of mail attachments, and the fact that they are also non-JavaBean compliant means that you can't easily use JavaBean systems with Mail messages. [I wrote a JavaMail-based Web client last week, and discovered that using JSTL I could say ${message.subject} but not ${message.content} because the MimeMessage doesn't conform to the JavaBean spec, despite there being a message.getContent() method)
It isn't possible for *us* to extend the specification either, we're not
Sun.
Nor was I suggesting that we should -- I was suggesting a replacement with a JavaMail API layer to provide backward compatibility.
Well hold on until things settle down, it all seems a bit up in the air here
at the moment :-)
I'll take this discussion over to the JAMES team, and hopefully then ApacheJ2EE and JAMES will move in the right direction.
Alex.
