geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: [JavaMail] Re: Geronimo standard Sun-API jars
Date Mon, 11 Aug 2003 09:22:33 GMT
Alex,

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

If you're talking about protocols, I agree, but if you're talking about Mime
(RFC 2048 et-al) and Message (RFC 822 et-al) these aren't implemented in the
refrence implementation but directly by the API, my original point.

It is this fact, rather than the possibly better option whereby they would
be marked in the API by interfaces and implemented in the RI
which makes me wonder if it is worth the effort of writing coles simply to
benefit from the ASFL.

Don't forget this excercise should not permit the extension of these classes
to include new functionality, any new functionality you did provide would
not be portable as it would not for part of the published javaMail API.

> The APIs don't, in themselves, provide the conformance. The
> implementation (com.sun...) packages provide the conformance/validation.

Actually they do, for Message and Mime related classes the implementation of
the RFC's *is* coded directly into the javax.mail packages.
It is possible to alter the performance and behavour of these classes using
the normal techniques of inheritance and overriding without having to go the
extreme length of writing clones of the classes and forcing a namespace
conflict with java.mail in order to have *your* methods invoked.

> In any case, the API for JavaMail tends to be bogged down with
> low-level representations (such as MimeBodyPart)

I agree with that, IMO there sould be a cleaner distinction between API
interfaces and implementations and I often wonder why Sun decided to put so
much implementation directly into the API, and not seperated into API and
RI.

> when it could present
> a more unified interface such as getAttachment().

MimeMessage.getAttachement() is very ,limiting and makes a great deal of
assumptions about the uses being made of the content.
Mime is a recursive format, and is supported in JavaMail by recursive
methods for parsing it, if you want/need getAttachements() functionality you
should write a Mime toolkit which would use the javaMail Mime parsing
methods to extract the data you require.

This would form part of another product, *we* could never add it to the API,
only Sun can do that.

> IMHO the JavaMail
> provides a low-level representation, which is less useful for
> developers wanting to send/receive mail.

It is also less useful for server applications owing to a number of initial
assumptions which seem to have coloured the architecture to focus on mail
clients.


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

An extended Mail API is not the same thing (see above) as rewriting the
javax.mail packages for licence convenience.
If you want to address these issues I would most strongly suggest that you
should be considering a creating seperate library of classes which  extend
javaMail classes to provide the utility you require.

It is an unfortuante fact that many people feel that JavaMail is inadequate
in one way or another, but unless you can bend Sun to your will it is
unlikely that that will change, and likewise it is not possible to re-create
javaMail in any way other than supporting the current classes and methods.
If you were to do so you would no longer have packages which were
interchangeable with javaMail.


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

This is an issue you need to raise with the javaMail developers, I don't see
how you can fix this independantly as to do so would *by definition* be to
create a different product, because javaMail would no longer be usable by
anything that uses your new functionality.

What do you believe MimeMessagegetContent() should return if not an Object?
Mime is capable of containing, recursively, a limitless number of
content-types, to make an arbitrary decision about the specific use to which
any part of any multipart message is being put doesn't make sense, in order
to make any sense of this method you have to know the content-type and make
some kind of handling decision.

It is possible to make a much simpler Mime API which makes these
assumptions, but I believe that the price of this simplicity is that it
won't perform correctly in every case.

I can see how Sun could possibly have made a less convoluted job of
javaMail, but Mime is a PITA in any language and any Mime API is bound to
reflect that if it is doing the job properly.

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

But what benefit would the replacement bring? anyone using it's "advanced"
features would no longer be able to use javaMail.
On the other hand providing a seperate set of javaMail extensions would
allow everyone to continue to use javaMail.

In the later case, and to return to my original point, is there anything to
be gained by cloning javaMail?

> I'll take this discussion over to the JAMES team, and hopefully then
> ApacheJ2EE and JAMES will move in the right direction.

Very good!, see you there. :-)

d.


Mime
View raw message