Sent from my iPhone
> On Feb 18, 2014, at 7:27 PM, Dennis Reedy > ... > BTW, I respectfully don't agree with > >> Rio was just an awfully large and complicated bit of code to “start” with. This is not my feeling, just what I have sensed over the years of conversation about why RIO was not THE choice to use or recommend. Gregg > Cheers > > Dennis > >> On Feb 18, 2014, at 724PM, Gregg Wonderly <ge...@cox.net> wrote: >> >> I’ll offer my observation from overheard discussions over the years, from a >> few, but varied Jini community members. But first, let me state that I am a >> pro Rio person (and Dennis I must apologize again for leaving it off of my >> slide at the Jini Community meeting in Europe). >> >> I’ve never used Rio in a deployment, but I’ve looked into it for a couple of >> different projects. My primary issue in my River deployments has always been >> delayed codebase downloads and proxy unmarshalling were needed because of >> network bandwidth restrictions, computer resource limitations and user >> interface speed to get my ServiceUI desktop to “display” all the icons. The >> large number of services that I deployed onto multiple machines, verses the >> few that anyone person would use. Would require deserialization of hundreds >> of proxies that would never be used. Windows restrictions on a handful of >> active sockets, max, would cause endpoints to “fail” to connect. There were >> all kinds of issues and I needed delayed unmarshalling to solve those >> issues. So, the solutions that I rolled into Jini 2.0/2.1 to solve these >> problems for me, provided some isolation from other things available in the >> community. >> >> Ultimately, I’ve been trying to push for a “container” specification for >> some time. My simple “startnow” project on java.net is where I’ve put most >> of the things that I’ve done to put things on top of Jini. The simple >> interface that Seven provides, is something that I think is a good start. >> >> My observation is that the community has stated in various conversations, >> that Rio was just an awfully large and complicated bit of code to “start” >> with. It is very powerful and very much an end to end solution to a lot of >> things, and that is what I understand people in the community to not want to >> “include” in their simple Jini services. >> >> Some of that probably comes from JavaEE experience or “knowledge” which >> makes them feel that Rio might just take them down the path of not being in >> control of much of anything and having to always have “the same” container >> for all their services when that might not be required. >> >> I am all about fixing things that need to be fixed, and standardizing things >> that as standards, don’t limit choices on evolving to better standards. >> >> That’s what we need to focus on. Because of the flexibility of River with >> so many endpoint implementations, flexible implementation details, etc., it >> is really an unfinished platform. There needs to be fewer “free” choices, >> and a lot more “refinement” of interfaces so that very specific issues are >> fixed for specific releases, but we can still evolve to create better and >> better experiences. >> >> These things have all been said before by members of this community. There >> are lots of experienced people here, and lots of people who have found >> “easier” ways to do things, because of the unfinished nature of the beast. >> >> We know, really need to start working on finishing things with solid >> limitations on choices where more choices just don’t make anything easier or >> more possible. >> >> Gregg >> >>> On Feb 18, 2014, at 11:50 AM, Dennis Reedy <dennis.re...@gmail.com> wrote: >>> >>> >>>> 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 >
