Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?

["Richard O. Hammer" <RO...@EarthLink.net>]

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 tasks of a server. ...

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 extended set, just for clients.  Then we developers of servers 
could employ the basic set without having to disentangle ourselves 
from the features intended for clients.

JavaMail includes a lot of important, basic work, promising to ease 
the burdens of other developers.  Because of this, we developers of 
servers find ourselves sucked in, trying to use the good stuff that is 
inside JavaMail for our purposes.  But JavaMail would be much more 
valuable to us if the basic tools were exposed free of the 
stipulations which have been added for clients.

Rich Hammer
Hillsborough, N.C.
mailscreen.net




---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?

["Richard O. Hammer" <RO...@EarthLink.net>]

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 able to quickly 
throw together a list of ways that life could be made easier for us if 
more of the basic functionality inside JavaMail were made accessible 
without the requirements for clients.  Assuming that I have actually 
represented the needs of James developers, I hope that others from 
this list might respond.

I don't know if a list of our needs might rise to the level of a 
"great advantage" from Sun's viewpoint.  You are probably right that 
there are many fewer server-side projects than client-side projects.

Rich Hammer


Bill Shannon wrote:
> 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 classes 
>> for many
>>  > of the tasks of a server. ...
>>
>> 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 extended set, just for clients.  Then we developers of servers 
>> could employ the basic set without having to disentangle ourselves 
>> from the features intended for clients.
>>
>> JavaMail includes a lot of important, basic work, promising to ease 
>> the burdens of other developers.  Because of this, we developers of 
>> servers find ourselves sucked in, trying to use the good stuff that is 
>> inside JavaMail for our purposes.  But JavaMail would be much more 
>> valuable to us if the basic tools were exposed free of the 
>> stipulations which have been added for clients.
> 
> 
> We did some of this.  We separated the pieces of JavaMail into the
> core API piece and the protocol provider pieces.  That allows you
> to pick just the pieces you need.
> 
> But we haven't considered carving the core API piece into multiple
> pieces.  And we wouldn't consider doing anything of that sort that
> would break compatibility with the existing API.  Requiring servers
> to carry around the additional "client" parts of the core API doesn't
> seem like a great burden.  I'd be more concerned about adding significant
> new server support that clients were required to carry around.
> 
> If you think some great advantage could be had by splitting the APIs in
> this way, tell me more.
> 
> I think the more interesting question is how much can we morph the APIs
> into something that's more useful for servers without compromising ease
> of use for clients?  I expect there to be many thousands of applications
> using JavaMail for client mail access.  I only expect tens (at most) of
> applications using JavaMail to implement mail server functions.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Let's just tell Sun to rewrite the JavaMail API. Was: What about IMAP support?

[Bill Shannon <bi...@sun.com>]

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 classes for 
> many
>  > of the tasks of a server. ...
> 
> 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 
> extended set, just for clients.  Then we developers of servers could 
> employ the basic set without having to disentangle ourselves from the 
> features intended for clients.
> 
> JavaMail includes a lot of important, basic work, promising to ease the 
> burdens of other developers.  Because of this, we developers of servers 
> find ourselves sucked in, trying to use the good stuff that is inside 
> JavaMail for our purposes.  But JavaMail would be much more valuable to 
> us if the basic tools were exposed free of the stipulations which have 
> been added for clients.

We did some of this.  We separated the pieces of JavaMail into the
core API piece and the protocol provider pieces.  That allows you
to pick just the pieces you need.

But we haven't considered carving the core API piece into multiple
pieces.  And we wouldn't consider doing anything of that sort that
would break compatibility with the existing API.  Requiring servers
to carry around the additional "client" parts of the core API doesn't
seem like a great burden.  I'd be more concerned about adding significant
new server support that clients were required to carry around.

If you think some great advantage could be had by splitting the APIs in
this way, tell me more.

I think the more interesting question is how much can we morph the APIs
into something that's more useful for servers without compromising ease
of use for clients?  I expect there to be many thousands of applications
using JavaMail for client mail access.  I only expect tens (at most) of
applications using JavaMail to implement mail server functions.


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org