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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
