river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: [Discuss] Please have a look at the River Container
Date Wed, 19 Feb 2014 21:13:02 GMT
+1 on what Dawid said.

It does seem like a much more effective approach to accept Rio, derive what
the standard looks like from it, and call that the v0.0.1 standard.  Rather
than going through a verbal exercise deciding what a container
specification should be.

I would then expect that as the community gets to know Rio the standard
would evolve (hopefully alongside the Rio code, to keep it compliant) into
something that others can converge their containers to if they so choose.


On Wed, Feb 19, 2014 at 1:06 PM, Greg Trasuk <trasukg@stratuscom.com> wrote:

>
> I've created a JIRA issue, https://issues.apache.org/jira/browse/RIVER-435to propose
an archive format and track discussion.
>
> Cheers,
>
> Greg Trasuk
>
> On Feb 18, 2014, at 9:27 PM, Dennis Reedy <dennis.reedy@gmail.com> wrote:
>
> > 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 <gergg@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.reedy@gmail.com>
> wrote:
> >>
> >>>
> >>> On Feb 18, 2014, at 1236PM, Greg Trasuk <trasukg@stratuscom.com>
> wrote:
> >>>
> >>>>
> >>>> Hi Dennis:
> >>>>
> >>>> Discussion intertwined...
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Greg.
> >>>>
> >>>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <dennis.reedy@gmail.com>
> wrote:
> >>>>
> >>>>>
> >>>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <trasukg@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
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message