Gregg, I think I stated earlier what I see as the primary issue here (and it seems you're echoing the same thing):
>>>> 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. Lets start with that first. BTW, I respectfully don't agree with > Rio was just an awfully large and complicated bit of code to “start” with. 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
