[JavaMail] Re: Geronimo standard Sun-API jars

[Alex Blewitt <Al...@ioshq.com>]

> I'm currently working on a belief that J2EE implies usage of standard 
> Sun
> specs. ie) it says use JavaMail rather than have a mail option. Will 
> read
> through the J2EE spec more to be able to put a better input in.

I don't think it mandates the use of JavaMail for everything. However, 
it does mandate that the JavaMail APIs be available to programs.

So we could use another implementation but provide a JavaMail API for 
it in order to work. How we could do that with the issues re: Sessions 
is a bit more problematic.

Alex.

RE: [JavaMail] Re: Geronimo standard Sun-API jars

["Noel J. Bergman" <no...@devtech.com>]

Danny wrote:
> Alex,
> > So we could use another implementation but provide a JavaMail API for
> > it in order to work. How we could do that with the issues re: Sessions
> > is a bit more problematic.

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

> I'd be very wary about starting down the road of an Apache clone of
javaMail
> unless it really offers serious advantages.

On this subject, and several others, there is talk with Sun.  Let's please
just focus on what is here for now, and give Sun some time to respond.
Everyone wants to move a lot faster than Sun is likely to do.  :-)

	--- Noel

RE: [JavaMail] Re: Geronimo standard Sun-API jars

["Noel J. Bergman" <no...@devtech.com>]

> o Easier API to use to generate/send mails
> o Less global configuration settings
> 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've got an implementation of Transport kicking around from before that
> I can donate to the project

The appropriate place would be James (james.apache.org), and we'd be willing
to give it a look if it provides substantial benefits to our server.

	--- Noel

RE: [JavaMail] Re: Geronimo standard Sun-API jars

[Danny Angus <da...@apache.org>]

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.

Re: [JavaMail] Re: Geronimo standard Sun-API jars

[Alex Blewitt <Al...@ioshq.com>]

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.

RE: [JavaMail] Re: Geronimo standard Sun-API jars

["Noel J. Bergman" <no...@devtech.com>]

> my sentiment would be for a asfj2ee-javamail-api.jar existing which
> contains the api and not the implementation made available.

The specification dictates if something is an interface or a class.  Other
(third party) code may extend one of those standard classes.  Therefore if
you don't have the right behavior in your class, that code isn't going to
work.

As has been said a couple of times by different people, Sun had no advance
notice of this project.  They will need a bit of time to decide how to
participate, so let's be patient.  Meanwhile, there are tons of other areas
to work on.  :-)

At least that's my advice.  :-)

	--- Noel

RE: [JavaMail] Re: Geronimo standard Sun-API jars

[Henri Yandell <ba...@generationjava.com>]

On Fri, 8 Aug 2003, Danny Angus wrote:

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

With this education having occurred, my sentiment would be for a
asfj2ee-javamail-api.jar existing which contains the api and not the
implementation made available. Sentiment could be utterly wrong though if
it's not possible.

Hen

RE: [JavaMail] Re: Geronimo standard Sun-API jars

[Danny Angus <da...@apache.org>]

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.

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

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

d.

Re: [JavaMail] Re: Geronimo standard Sun-API jars

[Alex Blewitt <Al...@bandlem.com>]

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

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

Alex.

RE: [JavaMail] Re: Geronimo standard Sun-API jars

[Danny Angus <da...@apache.org>]

Alex,

> So we could use another implementation but provide a JavaMail API for
> it in order to work. How we could do that with the issues re: Sessions
> is a bit more problematic.

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.

I'd be very wary about starting down the road of an Apache clone of javaMail
unless it really offers serious advantages.

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.

d.