Richard, > The critique of Alex's contribution is certainly well intended, > but its also > kind of odd. Why should the critic
I'm "the critic" my name is Danny Angus, I'm a comitter and PMC member of the Apache James mailserver project. I have a ton of experience with javaMail, much of it bad, yet I firmly believe that it may be a mistake for Geronimo to try to replace it when we should really be trying to implement it. > complain that there is not enough > planning and then go on to say that Alex's impl cannot be differentiated > from the Sun impl? If it cannot be differentiated, then what > prior planning > is necessary? A decision as to whether or not the geronimo community require this, want it, and are prepeared to maintain it ad-infinitum. We are *NOT* discussing an implementation of the API. I am *HAPPY* to see an implementation, and have offered to be part of that effort. What I want to know is whether or not Geronimo really wants to be burdened with the creation and maintenance od code which *replaces* the published API? Just because Alex is prepared to do the work is surely not alone reason enough to incorporate it and the risk it brings, the risk that the wider project will not be able to progress to release, or some such, for want of work on the Apache version of the javaMail API. Work which would not be necessary if we simply used Suns' public API. Please everyone note that I'm not talking about implementations, I'm talking about the API itself. > > I've spoken to some people who have attempted to use JavaMail in a high > volume production environment and abandoned it because it was too slow ... > IMO, if Alex can improve on that, than more power to him. What was too slow? the API or the Refrence implementation? Again, theres no clear distinction made by you, yet you would quite clearly distinguish between Tomcat (the servlet/jsp RI) and the API it implements. > I also believe that it behooves Geronimo to have its own implementation > because it gives us the option of going beyond the spec to impl > value-add-ons. As I said before, an implementation allows this, an alternative version of the API does not, not if it is correctly done. > > Anyway, the critique appears to have been offered in sincerity, but it > doesn't make much sense to me. I think perhaps you need to look at what is being done. Alex is creating a copy of the API, he's *NOT* implementing it. If he implements the API thats fine, thats what we're here for. Bearing in mind that this is not a case of simply typing in interface method signatures from the javadocs, why would creating and maintaining a copy of the javaMail API be a worthwhile goal of this project, should we not be focused on creating a world class implementation of it? d.
