On Feb 18, 2014, at 1113AM, Greg Trasuk <tras...@stratuscom.com> wrote:
> > Hi Dennis: > > I’ll bite twice: > > - Your offer to contribute Rio may have been before my time as a committer, > because I don’t recall the discussion (mind you I’m also at a loss to recall > what I had for dinner last night ;-). November 28th, 2013. Email thread entitled "River Container (was surrogate container)". You responded asking questions about code provenance. Snippet from the thread: I see it’s Apache licensed. Ideally we’d have a CCLA in place from all the corporate contributors, but I personally don’t know if that’s required if the contributed code is ASL2. We might have to consult more experienced Apache people. Greg. I'd like to find out what would need to be done here. If anyone could help, that would be great. I have no problems donating Rio to the River project. River would get a mature project, with tons of real-world application of River put into it. I think it would do River good, and also Rio. If not part of the project I think River should at least reference it as a notable project that can really speed developer adoption of River. > How was River unwelcoming, and do you feel the same situation exists now? > - Could you give a little detail on why you think container projects should > be outside River? Is it just development stickiness, or something else? It's not container projects in general. It's projects that were never accepted as *the* way to do something and now want to be included as defacto support into River. I see no reason that your contribution should be considered over more mature implementations at this point (Rio, Seven,...). I think most importantly, there is no specification for "containers" to implement, no requirements. The first thing to do would be to define what these are, then contributed implementations can appear, and developers/deployers choose what implementation to use. > > I’ll expand on why I think River needs a container desperately: Basically > there is no way for a developer to use Jini or River as it stands. I agree with your statement above, just use Rio :) > For reasons that we’ve talked about endlessly, the Service Starter approach > is unworkable (even without a potential race condition). That isn’t new - I > remember when I started using Jini many years ago, I spent at least two days > just bringing up Reggie. Then another two days getting a service running > The “new-user” experience has been an issue since before we came to Apache. > That’s why I wrote Harvester, that’s why Dennis created Rio, that’s why there > were half a dozen containers created. > In fact I suspect that every developer who’s ever used Jini did their own > container implementation, in one form or another. I'm not sure this is the case at all. Some did yes, most took advantage of what others had already written. Regards Dennis
