Alex wrote: > >From where, though? I had volunteered to do it, and worked away at > providing the implementation. From a community PoV, the files haven't been > in there very long but no doubt others will pick it up where it needs to > be handled.
This is not a given. Geronimo is a new project, there is great scope for new code ending up being orphaned if a community of interested people doesn't gel around it, there is no guarantee that this will happen. I want to emphasise that this is not intended to be > criticism of > > him in any way. > > Not taken as such, don't worry :-) I have a fairly thick skin (along with > a fairly thick body and a fairly thick skull) Nice one. :-) > However, one of the reasons it took me a long time to do in the > first place is that I didn't /just/ do the APIs -- I also implemented > (where possible) the methods that go with it. I think its important to clarify something here, if the method is a real method in Sun's API, not an interface method signature or an abstract method, then you *must* implement it or you haven't cloned the API. I'm sure you know this already, my "issue" is that there is a lot of this needed, and just making a first pass isn't (no disrespect) going to create anything that is worth having instead of Sun's API. >Gut feeling is that I've got > between 60% and 80% of the base implementation of the JavaMail API done. > (Key things missing are the MimeMessage and Folder methods, though some > are done). I really suspect that once you start into MimeMessage et-al you'll discover why Sun make this pert of the API and not simply an interface. I believe it is because the job (of conforming to the Mime RFC's) is complex and nasty and easily tested. Now I have some reservations about Sun's version from the API, but I believe that the way to solve that ought to be by Sun refactoring the implementation out of the API and into the RI. As it stands Sun's Mime parsers and related classes form part of the API, they are not interchangeable components like the Transport and Store mechanisms are. > For maintenance purposes, I am developing a set of JUnit tests which will > hopefully avoid the need (or difficulty) of too much maintenance. What I meant was that as the specifications (RFC's and the API's) evolve with time it will always be necessary for someone to be aware of these changes and "copy" them into geronimo's JavaMail clone. > To a greater extent (and certainly initially) this is true. But once the > core bits are done, it will be easier to maintain. Some of the RFCs are > implemented as Sun classes in 1.4 anyway Yep, I know, and if you look at it that way many more RFC's are implemented in the existing JavaMail API, not Sun's refrence implementation of the API, but the API itself. > >From a personal PoV, I've used JavaMail before and have had experience > with using it. I thought it might be fun to work on as an initial task > working with Geronimo. And it's better than writing up my thesis :-) Which is a valid reson for you to do this, and I respect that. What I am concerned with is that I haven't seen a valid reason to place this burden on Geronimo, not one that also takes account of the particular concerns I have. If I was sure that a majority of the comiters were aware of the issues, and hand taken a properly mandated decison to continue with this, then fine. However I have a feeling that thay aren't aware and haven't actually mandated this. > Yes, this is indeed the case. In fact, the only parts where we could > differ would be in the implementation of the actual transport/stores > anyway, since the API is firmly fixed in how its supposed to behave. Yes, this is again a point which I feel is being confused. The Transports and Stores and other classes distributed in the "com.sun" packages are Sun's "refrence implementation" of the API, these are fully within the scope of this project and offer an opportunity to add value and functionality within the specification of the API. The rest of the classes, those in the "javax.mail" packages ARE The API, they are not an implementation of the API they are it and it is them, period. > The J2EE 1.4 spec mandates a JavaMail implementation of some kind; > whether this be based on the Sun RI or another open-source one is still open. Ok, I understand. But someone answer this.. An implementation of the API would depend upon the API code, and would replcae the "com.sun" refrence implementation. Anything which was capable of being used wholly in place of the API would be an alternative API, not an implementation. Are we not therfore creating an alternative when we should actually be creating an implementation? > o To provide JavaMail integration with Geronimo without dependency on > Sun's JavaMail (Mainly for licensing reasons) I understand this, but don't believe that this alone is worth the effort needed to create and maintain this code. > o To provide an Apache implementation of the mail store/transport > protocols This *IS* an implementation and I agree this *SHOULD* be the focus of the javaMail effort. > o Subsequently to make the same version available as part of the > jakarta-commons packages, for possible integration into other Apache > products like JAMES This is only likely to happen if there is some demand for it, something which I am not convinced of. After all Sun's API is released under a licence open *enough* for James to use it and not bother maintaining a duplicate of this functionality. Think re-use. > > I have heard that the ASF are in talks with Sun regarding licensing their > JavaMail implementation through an open-source license. Whatever. Thats about the implementation, the "com.sun" things, not the API, the "javax.mail" things. > Should this come > about, then clearly the work I will have done implementing the APIs will > become obsolete and the correct decision will be to replace them with > Sun's implementation. Actually if that happens it will be _Apache's_ implementation, like Tomcat is Apache's implementation of Servlet & JSP. Apache doesn't maintain the servlet and jsp API's, nor AFAIK an ASFL clone of these API's. Yes, but what I have a probelm with is not your implementation, but the need for creating a whole replacement API, and where the resources will come from to maintain it once your enthusiasm wanes. > As yet, however, I don't know what stage this is at, > so feel that it is worth gambling to make it available now and for the > initial, if not subsequent, releases of Geronimo. Make the *implementation* availabe, yes thats a Good Thing, whatever happens. But to replicate the API for the sake of the licence alone is another matter altogether. > It has also given me opportunity to work with ASF; something which I've > not done before and it's been pretty enjoyable :-) Good, I'm glad about that, it's a good place to be, don't let my politiking put you off. :-) d.
