> Richard O. Hammer wrote:
Another class which does more than I want is Transport.
... it sets message headers
Bill Shannon wrote:
I'm not sure what you're referring to.
You are right Bill. I wrote based upon my poor memory of experiments
I did a year ago or more. I had noticed that headers wer
Bill Shannon wrote:
> > One detailed reason I find MimeMessage less than ideal is that Message
> > contains the method saveChanges(), and Method.saveChanges() re-writes
the
> > Message-ID header.
> > The alternative, the compromise position I'd like to propose is this:
> > > Message.saveChanges()
Richard O. Hammer wrote:
I want to add a few observations to what Danny has already said in this
thread. I mention two classes, Message and Transport, which I think
could be improved by being super-classed, by giving each of them a
simpler parent. But this is based upon my limited experience w
One detailed reason I find MimeMessage less than ideal is that Message
contains the method saveChanges(), and Method.saveChanges() re-writes the
Message-ID header.
James wastes clock cycles saving and restoring Message-ID when message
contents change.
Surely it is more efficient for saveChanges() t
I want to add a few observations to what Danny has already said in
this thread. I mention two classes, Message and Transport, which I
think could be improved by being super-classed, by giving each of them
a simpler parent. But this is based upon my limited experience with
using JavaMail's API
Bill,
> But, to some extent, it's a matter of taste.
I completely agree.
JavaMail, like James, is a quiet success, there is very much more
untroubled use of the product than action on the develpment front. This is
for us and I assume for you, a strong indicator that you're doing the right
t
I don't believe that it is necessary to split the API per se, but consider
it this way..
A mail-client API and a mail-server API would be specialisations of a
generic mail API.
The generic API would be composed mainly of interfaces, and implementation
would be done by the specialisations.
This is r
Bill!
And after I just bad mouthed you! So first I offer my heartfelt apology.
:-)
Also sorry for cross posting, I suggest we keep this discussion in one
place, James-dev is quite quiet.
You wrote:
> We did some of this. We separated the pieces of JavaMail into the
> core API piece and th
Thank you, Bill.
Even though I raised this point, I doubt that I'm the best person from
the James Developers list to respond to your saying, "If you think
some great advantage could be had by splitting the APIs in this way,
tell me more."
I guess that Danny, Noel, Serge, or others, might be ab
Richard O. Hammer wrote:
Danny Angus wrote:
> ... JavaMail is explicitly and
> in its detail a mail client API, it lacks support in may areas for
the kind
> of server functionality James provides and it is not always easy, and
often
> impossible, to force James to use JavaMail interfaces and
Rch,
> Reflecting upon what Danny wrote, I wonder if Sun ever considered the
> possibility of dividing the existing functionality in the JavaMail
> API. It would be great for us if this existing functionality were
> divided into a basic set, tools useful to both servers and clients,
> and an
Danny Angus wrote:
> ... JavaMail is explicitly and
> in its detail a mail client API, it lacks support in may areas for
the kind
> of server functionality James provides and it is not always easy,
and often
> impossible, to force James to use JavaMail interfaces and classes
for many
> of the ta
12 matches
Mail list logo
