On Feb 18, 2014, at 1236PM, Greg Trasuk <tras...@stratuscom.com> wrote:
> > Hi Dennis: > > Discussion intertwined… > > Cheers, > > Greg. > > On Feb 18, 2014, at 11:45 AM, Dennis Reedy <dennis.re...@gmail.com> wrote: > >> >> 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. >> > > OK, let’s assume that you’re willing to contribute Rio, and that the River > community is in favour. I’ll start a separate thread to discuss the steps. > > And we should go ahead and add a reference to Rio on the River site in the > meantime. While we’re at it, any other projects that should be referenced? > The “notable projects” idea is a very good one. Great! > >> >>> 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. >> > > OK, fair point. No specifications, I agree with. FWIW, the container I > wrote uses the Service Starter conventions, which is why it’s able to use > Reggie unmodified. Right, as does Rio. Any service that can be started with River's Service Starter starts out of the box with Rio. > The only thing added is the packaging into a single archive file. So, I > hereby propose that we adopt a service archive packaging standard that looks > like the one in the container (discussion will no doubt follow). You can propose this, at this point I dont know what it looks like or whether it will be the way we move forward. > > To be clear, though, I’m not suggesting that river-container should be “the” > way, just “a” way. Then it should be outside of the main River project, and referenced as a notable project. > And there was no small amount of real-world application experience that went > into river-container. > >>> >>> 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 :) > > Can I at least get you to agree that there should be at least one container > that’s part of the River project? Possibly more than one, that serve > different targets? > > I recall that years ago, on Jini-users, John McClain commented that the Jini > team didn’t want to sanction a single style of deploying services. While I > suspect that logic still holds, it’s pretty clear to me that the core project > needs to have at least “a” container. And it does, ServiceStarter. Dennis
