I'm also a big fan of Rio and its multi-module service build structure and the use of Maven for code distribution. Any decision to select an alternative container as a de facto standard would be ill-advised, in my opinion. Not to say Rio has to be the standard, but if it's not it should be of equal stature with any others given its capability and maturity.
Incidentally, I don't think it's necessary to have Rio as part of River for Rio to be successful, even if it were to be designated the de facto standard River container. I can see how having the Apache governance process for specs and standards has its merits, and I appreciate the difficult conversations that have been happening lately in this community. But I have come to prefer the GitHub model of collaborative development and if this community embraced Rio I think it might better blossom in GitHub with core River remaining at Apache. However, I trust Dennis on this and support his and this community's decision on the matter. -jeff On Tue, Feb 18, 2014 at 11:38 PM, Dawid Loubser <da...@travellinck.com>wrote: > Op Di, 2014-02-18 om 21:27 -0500 skryf Dennis Reedy: > > BTW, I respectfully don't agree with > > Rio was just an awfully large and complicated bit of code to "start" with. > > > As a user of Rio, and being somewhat familiar with its internal workings, I > also have to disagree with that statement. > > While there is if course no "public standard" that describes the contract of > the Rio environment, > it is itself very cleanly split between the specifications and the > implementation. > > Furthermore, the domain-specific language language that describes deployments > could easily be formalised as the basis of a standard, > as it is independent of the implementation. > > I don't think there is any substantial effort involved in completely > separating, and using as the basis of a "standard", the > API / Specification / Configuration artifacts of Rio. > > Finally, though there are of course some complicated bits in something with > this level of sophistication, the code base is not "awfully large" - > certainly by my standards. > > I think that it's very exciting that Rio is being considered for standard > inclusion in the River toolkit. It can only do both very well. > > As somebody who has written River (Jini) code without Rio, and then with, I > would never even consider doing it without Rio (or something similar). > Many others probably feel this way too. > > I do sometimes wonder about the practical future of the code-downloading > model (not to mention strong typing) in the face of the > massive JSON/HTTP onslaught, even though the world really needs it (they just > don't know it yet :-) > > kind regards, > > > - > > DAWID LOUBSER > Systems Architect - Travellinck International > Johannesburg, South Africa > ------------------------------------------------------- > mailto:da...@travellinck.com (E-Mail)http://www.travellinck.com > (Web)xmpp:dawid.loub...@jabber.me (Jabber)xmpp:dawid.loub...@gmail.com > (Google Talk, deprecated) > skype:dawid.loubser (Skype) > ------------------------------------------------------- > > > > Op Di, 2014-02-18 om 21:27 -0500 skryf Dennis Reedy: > > 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 > >
