You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2014/02/18 16:11:54 UTC
[Discuss] Please have a look at the River Container
Hi all:
For the past little while, I’ve been working on the Apache River Container (feel free to suggest a better name), which was originally the Surrogate container.
I haven’t asked for any help or encouraged collaboration so far (although the project has been in the Apache River repo, so you’ve seen the commit messages), mainly because I hadn’t crystallized the architecture enough to explain it to anyone. I find that happens in a new project - you need to flesh out the concepts before you can talk about them.
That phase of the project is done, I think. It’s time to invite some other people in.
So, I wonder if I could ask you all to have a look at the container, and perhaps help finish it off?
The goal of the container was originally to implement the Surrogate Specification, but it rapidly changed. The new goal is to:
- Create an easily usable deployment environment for Jini/River services and service consumers (i.e. much simpler to use than the Service Starter framework - much more like a servlet container).
- Specifically solve our “First Fifteen Minutes” problem.
The container allows “copy and paste” deployment of service modules. Basically, you package your service into a single archive file that includes the service’s jars as well as the codebase jars, then copy that archive into the container’s deployment directory. The container starts up the service in its own class loader, protected by appropriate Permissions, and publishes the codebase jars on a local web server. You can deploy multiple applications to a given startup profile. By default, the container includes starts Reggie and Mahalo, so it’s a one-stop deployment (obviously in a real SOA you wouldn’t want the infrastructure services in every container, but it’s handy for development). It also provides a similar environment to run service consumer (client) applications - after all, a client might also want to publish service endpoints, e.g. for notifications.
Obviously, it’s not a released project, so right now you have to build from source. The source is in Apache’s git repository at https://git-wip-us.apache.org/repos/asf/river-container.git. If you’re not a ‘git’ user, you can download a snapshot from https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=snapshot;h=4f7b49be7129170a4a274b7867e2fb5ee0965376;sf=tgz as a ‘tar.gz' file.
Apache’s git browser doesn’t format the README file (it’s in Markdown), so you might prefer to read it from my github repo at https://github.com/trasukg/river-container/blob/master/README.md. It contains a “First Fifteen Minutes” evaluation guide.
Eventually I’d like to propose this container as an additional deliverable from the River project. For now, please have a look at it and give feedback, particularly on the “First Fifteen Minutes” experience.
As far as contributions, I’m hoping that looking at the current state will generate a wish list, and then we can see who wants to do what. Right now, my immediate wish list is to have a Maven plugin to do the deployment (I’ve started work in that direction) and some admin. Later, I’d like to see integration with the SSL-based JERI endpoints (mainly I think we need to have the container be aware of the key store), better thread handling (which requires changes to the jtsk platform, unfortunately), JNDI database connections, and then an annotation-based service definition model. I’m looking forward to hearing others’ comments.
By the way, inevitably this container will be compared to Rio and other containers, and someone will ask “Why didn’t you just use Rio (or ‘startnow', or Seven, etc)?” What can I say? I had a different itch to scratch. Rio includes quality-of-service handling that I didn’t need, and I wanted a container that had a similar deployment model to Tomcat, so I wrote it inside the Apache River project. People are also encouraged to look at Rio, and if the Rio group wants to contribute code to River, we should welcome them. I’ve always thought there’s room for diversity in how we deploy services, although we probably should encourage a packaging and service-definition standard. I think we’re all in agreement that we can do better than the Service Starter framework.
Cheers,
Greg Trasuk
Re: [Discuss] Please have a look at the River Container
Posted by Sam Chance <sg...@gmail.com>.
Greg,
FWIW, I agree with you. I find the lack of relative ease of use is the
number one adoption inhibitor of Jini, now River. Further, the idea of
creating something that is not in the mainstream group thought process will
be greeted with lengthy and detailed rationale for why it's not the way to
go.
I introduce distributed OSGi, Jini/River, and Paremus to developers who
become intrigued and fascinated. However, the lack of relative simplicity
and reliable, straightforward methodologies invariably lead to confusion
and drifting away toward classic JEE approaches.
There was a DARPA program called Control of Agent Based Systems (CoABS),
which I believe started in the late 90s. It basically created an
abstraction over Jini. It was comparatively much easier than Jini. IMHO,
it's too bad the software wasn't "stanadardized" and released as free and
open source software. Having said that, there is a version of it
available on sourceforge called Intelligent Services Layer (ISL). (
http://sourceforge.net/projects/isl-soa/). I'm not sure what, if any,
license applies. But I thought I would share it with you.
Again, in my opinion, if you have a vision with this technology, I
recommend you run with it, even if you have to somehow fork or create a new
project. You will very likely not garner support from others on this group.
If you do move forward with this, please feel free to add me to any
notification list. I believe the underlying model is sound and useful. So
anything that makes it more easily adopted is interesting to me.
Thank you!
Sam
On Feb 18, 2014 10:12 AM, "Greg Trasuk" <tr...@stratuscom.com> wrote:
>
> Hi all:
>
> For the past little while, I've been working on the Apache River Container
> (feel free to suggest a better name), which was originally the Surrogate
> container.
>
> I haven't asked for any help or encouraged collaboration so far (although
> the project has been in the Apache River repo, so you've seen the commit
> messages), mainly because I hadn't crystallized the architecture enough to
> explain it to anyone. I find that happens in a new project - you need to
> flesh out the concepts before you can talk about them.
>
> That phase of the project is done, I think. It's time to invite some
> other people in.
>
> So, I wonder if I could ask you all to have a look at the container, and
> perhaps help finish it off?
>
> The goal of the container was originally to implement the Surrogate
> Specification, but it rapidly changed. The new goal is to:
> - Create an easily usable deployment environment for Jini/River
> services and service consumers (i.e. much simpler to use than the Service
> Starter framework - much more like a servlet container).
> - Specifically solve our "First Fifteen Minutes" problem.
>
> The container allows "copy and paste" deployment of service modules.
> Basically, you package your service into a single archive file that
> includes the service's jars as well as the codebase jars, then copy that
> archive into the container's deployment directory. The container starts up
> the service in its own class loader, protected by appropriate Permissions,
> and publishes the codebase jars on a local web server. You can deploy
> multiple applications to a given startup profile. By default, the
> container includes starts Reggie and Mahalo, so it's a one-stop deployment
> (obviously in a real SOA you wouldn't want the infrastructure services in
> every container, but it's handy for development). It also provides a
> similar environment to run service consumer (client) applications - after
> all, a client might also want to publish service endpoints, e.g. for
> notifications.
>
> Obviously, it's not a released project, so right now you have to build
> from source. The source is in Apache's git repository at
> https://git-wip-us.apache.org/repos/asf/river-container.git. If you're
> not a 'git' user, you can download a snapshot from
> https://git-wip-us.apache.org/repos/asf?p=river-container.git;a=snapshot;h=4f7b49be7129170a4a274b7867e2fb5ee0965376;sf=tgzas a 'tar.gz' file.
>
> Apache's git browser doesn't format the README file (it's in Markdown), so
> you might prefer to read it from my github repo at
> https://github.com/trasukg/river-container/blob/master/README.md. It
> contains a "First Fifteen Minutes" evaluation guide.
>
> Eventually I'd like to propose this container as an additional deliverable
> from the River project. For now, please have a look at it and give
> feedback, particularly on the "First Fifteen Minutes" experience.
>
> As far as contributions, I'm hoping that looking at the current state will
> generate a wish list, and then we can see who wants to do what. Right now,
> my immediate wish list is to have a Maven plugin to do the deployment (I've
> started work in that direction) and some admin. Later, I'd like to see
> integration with the SSL-based JERI endpoints (mainly I think we need to
> have the container be aware of the key store), better thread handling
> (which requires changes to the jtsk platform, unfortunately), JNDI database
> connections, and then an annotation-based service definition model. I'm
> looking forward to hearing others' comments.
>
> By the way, inevitably this container will be compared to Rio and other
> containers, and someone will ask "Why didn't you just use Rio (or
> 'startnow', or Seven, etc)?" What can I say? I had a different itch to
> scratch. Rio includes quality-of-service handling that I didn't need, and
> I wanted a container that had a similar deployment model to Tomcat, so I
> wrote it inside the Apache River project. People are also encouraged to
> look at Rio, and if the Rio group wants to contribute code to River, we
> should welcome them. I've always thought there's room for diversity in how
> we deploy services, although we probably should encourage a packaging and
> service-definition standard. I think we're all in agreement that we can do
> better than the Service Starter framework.
>
> Cheers,
>
> Greg Trasuk
>
>
>
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> Hi Dennis:
>
> Discussion intertwined…
>
> Cheers,
>
> Greg.
>
> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
>
>>
>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
Re: [Discuss] Please have a look at the River Container
Posted by Peter Firmstone <ji...@zeus.net.au>.
Haven't had time to participate in the latest conversation.
1. Would like to see River adopt Rio's conventions at the very least
as part of the new standard, also like to see Maven provisioning.
2. Dennis, if you're interested, I'd be prepared to be one of your
developers for RIO, if you decided to go the incubator route.
3. Greg, for River container, I think we need to document whether
certain classes are thread safe or not, using annotations. Also
I'd tend to favour constructors for dependency injection, rather
than fields, since this allows for immutability.
4. I've found, making old code thread safe is very hard, mutibility
is very hard. When you take advantage of immutability, you can
use java.util.concurrent classes for controlling mutable state, or
thread confine mutable state, then safely publish when you've
finished mutating, never mutate again after publishing, but mutate
a new object and replace the old one instead.
Regards,
Peter.
On 20/02/2014 9:24 AM, Greg Trasuk wrote:
>>> The standard I proposed is what is currently implemented by River-Container. Rio’s convention is very much different, and relies on reading jar files from a Maven repository rather than from the local file system. It represents a radical departure from the Service-Starter conventions, although it is compatible with the services.
>> This is false. Rio provides the capability to declare a service be loaded either by artifact resolution or by using declared jars. I have never moved away from the latter approach for the simple reason that there are deployments that require legacy support.
> My mistake. Thank you for the correction.
>
>> Using an artifact to annotate a codebase, or to resolve a service's classpath provides significant advancement in the build-deploy lifecycle for developers, and also provides performance benefits when accessing a service's codebase (as well as addressing perm-gen oome for containers).
>>
> Makes a lot of sense. It’s something I’m intending to look into.
>
>> I'm thinking that way too. For now, I am withdrawing my offer of donating Rio to River. My intention was that it would greatly benefit River, by dramatically improving the out of box experience. I'll be happy if River would just mention it as a notable project that may be beneficial to developers getting to know River.
>>
>> I'll also comment on your service archive standard, and if reasonable (and given time) I'll provide support for it in Rio.
>>
> I recognize your earlier concerns about the River project appearing to favour one container over another. As such I’ll continue development of the River-Container outside the Apache River project. I guess it’ll need a new name.
>
> I’m not sure if we should leave River-435 open to discuss the service packaging. Perhaps others can comment...
>
>> Regards
>>
>> Dennis
> Cheers,
>
> Greg Trasuk
>
>
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
Greg,
Please add this to River-435
Thanks
Dennis
On Feb 19, 2014, at 905PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> On Feb 19, 2014, at 8:43 PM, Dennis Reedy <de...@gmail.com> wrote:
>
>>
>> On Feb 19, 2014, at 624PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>
>>> I’m not sure if we should leave River-435 open to discuss the service packaging.
>>
>> I think we should continue this discussion, lets leave it open.
>>
>
> OK, so on the topic of the jar file naming conventions (hello-api.jar, hello-proxy.jar, hello-impl.jar, etc), I thought we had already adopted that as a recommended convention. It follows common “good practices” that most of us have used for a long time, and it allows you to build without ‘classdepandjar’. As well, it happens to dovetail nicely with a Maven build.
>
> Having said that, I don’t believe that convention needs to be mentioned in the single-archive packaging spec (or at least not required - I suppose it could be referenced as good practice).
>
> The spec differentiates between “class path” and “codebase” jars by having them in different folders inside the deployment archive (lib and lib-dl). So, while the build that creates the archive may very well use the conventions to determine which dependent files go into which folder, from the container’s point of view, it doesn’t care about the naming conventions. Basically, everything in the ‘lib’ dir gets included in the service’s class path, and everything in the ‘lib-dl’ dir gets published through the codebase server and included in the service’s codebase annotation. In fact, a service may want to include other jar files in either its codebase or class path (for instance domain objects). These other jar files shouldn’t be forced into a River convention, especially since that might require renaming or repackaging the jar files.
>
>
>> Regards
>>
>> Dennis
>
> Cheers,
>
> Greg Trasuk
>
>
Re: [Discuss] Please have a look at the River Container
Posted by Jeff Ramsdale <je...@gmail.com>.
No, services shouldn't be required to use this standard but the
River-provided services should model it as the best practice, as mentioned
in another thread.
-j
On Wed, Feb 19, 2014 at 6:05 PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> On Feb 19, 2014, at 8:43 PM, Dennis Reedy <de...@gmail.com> wrote:
>
> >
> > On Feb 19, 2014, at 624PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> >>
> >> I'm not sure if we should leave River-435 open to discuss the service
> packaging.
> >
> > I think we should continue this discussion, lets leave it open.
> >
>
> OK, so on the topic of the jar file naming conventions (hello-api.jar,
> hello-proxy.jar, hello-impl.jar, etc), I thought we had already adopted
> that as a recommended convention. It follows common "good practices" that
> most of us have used for a long time, and it allows you to build without
> 'classdepandjar'. As well, it happens to dovetail nicely with a Maven
> build.
>
> Having said that, I don't believe that convention needs to be mentioned in
> the single-archive packaging spec (or at least not required - I suppose it
> could be referenced as good practice).
>
> The spec differentiates between "class path" and "codebase" jars by having
> them in different folders inside the deployment archive (lib and lib-dl).
> So, while the build that creates the archive may very well use the
> conventions to determine which dependent files go into which folder, from
> the container's point of view, it doesn't care about the naming
> conventions. Basically, everything in the 'lib' dir gets included in the
> service's class path, and everything in the 'lib-dl' dir gets published
> through the codebase server and included in the service's codebase
> annotation. In fact, a service may want to include other jar files in
> either its codebase or class path (for instance domain objects). These
> other jar files shouldn't be forced into a River convention, especially
> since that might require renaming or repackaging the jar files.
>
>
> > Regards
> >
> > Dennis
>
> Cheers,
>
> Greg Trasuk
>
>
>
Re: [Discuss] Please have a look at the River Container
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Feb 19, 2014, at 8:43 PM, Dennis Reedy <de...@gmail.com> wrote:
>
> On Feb 19, 2014, at 624PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>
>> I’m not sure if we should leave River-435 open to discuss the service packaging.
>
> I think we should continue this discussion, lets leave it open.
>
OK, so on the topic of the jar file naming conventions (hello-api.jar, hello-proxy.jar, hello-impl.jar, etc), I thought we had already adopted that as a recommended convention. It follows common “good practices” that most of us have used for a long time, and it allows you to build without ‘classdepandjar’. As well, it happens to dovetail nicely with a Maven build.
Having said that, I don’t believe that convention needs to be mentioned in the single-archive packaging spec (or at least not required - I suppose it could be referenced as good practice).
The spec differentiates between “class path” and “codebase” jars by having them in different folders inside the deployment archive (lib and lib-dl). So, while the build that creates the archive may very well use the conventions to determine which dependent files go into which folder, from the container’s point of view, it doesn’t care about the naming conventions. Basically, everything in the ‘lib’ dir gets included in the service’s class path, and everything in the ‘lib-dl’ dir gets published through the codebase server and included in the service’s codebase annotation. In fact, a service may want to include other jar files in either its codebase or class path (for instance domain objects). These other jar files shouldn’t be forced into a River convention, especially since that might require renaming or repackaging the jar files.
> Regards
>
> Dennis
Cheers,
Greg Trasuk
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 19, 2014, at 624PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> I’m not sure if we should leave River-435 open to discuss the service packaging.
I think we should continue this discussion, lets leave it open.
Regards
Dennis
Re: [Discuss] Please have a look at the River Container
Posted by Greg Trasuk <tr...@stratuscom.com>.
>>
>> The standard I proposed is what is currently implemented by River-Container. Rio’s convention is very much different, and relies on reading jar files from a Maven repository rather than from the local file system. It represents a radical departure from the Service-Starter conventions, although it is compatible with the services.
>
> This is false. Rio provides the capability to declare a service be loaded either by artifact resolution or by using declared jars. I have never moved away from the latter approach for the simple reason that there are deployments that require legacy support.
My mistake. Thank you for the correction.
>
> Using an artifact to annotate a codebase, or to resolve a service's classpath provides significant advancement in the build-deploy lifecycle for developers, and also provides performance benefits when accessing a service's codebase (as well as addressing perm-gen oome for containers).
>
Makes a lot of sense. It’s something I’m intending to look into.
>>
>
> I'm thinking that way too. For now, I am withdrawing my offer of donating Rio to River. My intention was that it would greatly benefit River, by dramatically improving the out of box experience. I'll be happy if River would just mention it as a notable project that may be beneficial to developers getting to know River.
>
> I'll also comment on your service archive standard, and if reasonable (and given time) I'll provide support for it in Rio.
>
I recognize your earlier concerns about the River project appearing to favour one container over another. As such I’ll continue development of the River-Container outside the Apache River project. I guess it’ll need a new name.
I’m not sure if we should leave River-435 open to discuss the service packaging. Perhaps others can comment...
> Regards
>
> Dennis
Cheers,
Greg Trasuk
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 19, 2014, at 450PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> There’s more than one possible container standard. River-Container is as valid as Rio, and is already part of River, having been developed inside the project.
>
> The standard I proposed is what is currently implemented by River-Container. Rio’s convention is very much different, and relies on reading jar files from a Maven repository rather than from the local file system. It represents a radical departure from the Service-Starter conventions, although it is compatible with the services.
This is false. Rio provides the capability to declare a service be loaded either by artifact resolution or by using declared jars. I have never moved away from the latter approach for the simple reason that there are deployments that require legacy support.
Using an artifact to annotate a codebase, or to resolve a service's classpath provides significant advancement in the build-deploy lifecycle for developers, and also provides performance benefits when accessing a service's codebase (as well as addressing perm-gen oome for containers).
>
> You know, when I read Sam Chance’s email last night, and he commented "Further, the idea of
> creating something that is not in the mainstream group thought process will be greeted with lengthy and detailed rationale for why it's not the way to go”, and then "You will very likely not garner support from others on this group“, I found it kind of depressing. I don’t want to believe that the River community is that fundamentally broken. But it appears he might be right.
>
I'm thinking that way too. For now, I am withdrawing my offer of donating Rio to River. My intention was that it would greatly benefit River, by dramatically improving the out of box experience. I'll be happy if River would just mention it as a notable project that may be beneficial to developers getting to know River.
I'll also comment on your service archive standard, and if reasonable (and given time) I'll provide support for it in Rio.
Regards
Dennis
Re: [Discuss] Please have a look at the River Container
Posted by Greg Trasuk <tr...@stratuscom.com>.
There’s more than one possible container standard. River-Container is as valid as Rio, and is already part of River, having been developed inside the project.
The standard I proposed is what is currently implemented by River-Container. Rio’s convention is very much different, and relies on reading jar files from a Maven repository rather than from the local file system. It represents a radical departure from the Service-Starter conventions, although it is compatible with the services.
Fundamentally, I don’t see the problem here, and frankly I don’t see why we are side-tracking anything with a discussion of packaging standards. In truth, I wrote up the proposed spec just to get the idea of “there’s no spec” off the table. It’s an implementation detail anyway.
Are we talking about rejecting years of work on River-Container because there’s another possible practice out there? Cause that’s insane.
There is no conflict between Rio and any other service deployment standard, and no need to choose one or the other. Neither one carries any negative effects for anyone currently using River. They address different needs. As evidence, witness the fact that there _are_ and _always were_ different approaches to deploying services.
Would the River community rather not have either product as part of River? Would the community prefer to bring in Rio and dump River-Container? If either of these cases is true, just everyone say so, and I will go on cheerfully developing on GitHub. But I think that would be a great loss to the River project. Honestly, how many new users are we attracting with the status quo?
You know, when I read Sam Chance’s email last night, and he commented "Further, the idea of
creating something that is not in the mainstream group thought process will be greeted with lengthy and detailed rationale for why it's not the way to go”, and then "You will very likely not garner support from others on this group“, I found it kind of depressing. I don’t want to believe that the River community is that fundamentally broken. But it appears he might be right.
Greg.
On Feb 19, 2014, at 4:13 PM, Tom Hobbs <tv...@googlemail.com> wrote:
> +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 <tr...@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 <de...@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 <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 <de...@gmail.com>
>> wrote:
>>>>
>>>>>
>>>>> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com>
>> wrote:
>>>>>
>>>>>>
>>>>>> Hi Dennis:
>>>>>>
>>>>>> Discussion intertwined...
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Greg.
>>>>>>
>>>>>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com>
>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
>>>
>>
>>
Re: [Discuss] Please have a look at the River Container
Posted by Tom Hobbs <tv...@googlemail.com>.
+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 <tr...@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 <de...@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 <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 <de...@gmail.com>
> wrote:
> >>
> >>>
> >>> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com>
> wrote:
> >>>
> >>>>
> >>>> Hi Dennis:
> >>>>
> >>>> Discussion intertwined...
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Greg.
> >>>>
> >>>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com>
> wrote:
> >>>>
> >>>>>
> >>>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
> >
>
>
Re: [Discuss] Please have a look at the River Container
Posted by Greg Trasuk <tr...@stratuscom.com>.
I’ve created a JIRA issue, https://issues.apache.org/jira/browse/RIVER-435 to propose an archive format and track discussion.
Cheers,
Greg Trasuk
On Feb 18, 2014, at 9:27 PM, Dennis Reedy <de...@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 <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 <de...@gmail.com> wrote:
>>
>>>
>>> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>
>>>>
>>>> Hi Dennis:
>>>>
>>>> Discussion intertwined…
>>>>
>>>> Cheers,
>>>>
>>>> Greg.
>>>>
>>>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
>
Re: [Discuss] Please have a look at the River Container
Posted by Jeff Ramsdale <je...@gmail.com>.
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:dawid@travellinck.com (E-Mail)http://www.travellinck.com (Web)xmpp:dawid.loubser@jabber.me (Jabber)xmpp:dawid.loubser@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 <de...@gmail.com> wrote:> >> >> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:>> >>> >>> Hi Dennis:>>> >>> Discussion intertwined...>>> >>> Cheers,>>> >>> Greg.>>> >>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:>>> >>>> >>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
>
>
Re: [Discuss] Please have a look at the River Container
Posted by Dawid Loubser <da...@travellinck.com>.
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:dawid@travellinck.com (E-Mail)
http://www.travellinck.com (Web)
xmpp:dawid.loubser@jabber.me (Jabber)
xmpp:dawid.loubser@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 <de...@gmail.com> wrote:
> >
> >>
> >> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:
> >>
> >>>
> >>> Hi Dennis:
> >>>
> >>> Discussion intertwined…
> >>>
> >>> Cheers,
> >>>
> >>> Greg.
> >>>
> >>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
> >>>
> >>>>
> >>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
>
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
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 <de...@gmail.com> wrote:
>
>>
>> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>
>>>
>>> Hi Dennis:
>>>
>>> Discussion intertwined…
>>>
>>> Cheers,
>>>
>>> Greg.
>>>
>>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
>>>
>>>>
>>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
Re: [Discuss] Please have a look at the River Container
Posted by Gregg Wonderly <ge...@cox.net>.
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 <de...@gmail.com> wrote:
>>>
>>>
>>>> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>>>>
>>>>
>>>> Hi Dennis:
>>>>
>>>> Discussion intertwined…
>>>>
>>>> Cheers,
>>>>
>>>> Greg.
>>>>
>>>>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
>
Re: [Discuss] Please have a look at the River Container
Posted by Gregg Wonderly <ge...@cox.net>.
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 <de...@gmail.com> wrote:
>
> On Feb 18, 2014, at 1236PM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>>
>> Hi Dennis:
>>
>> Discussion intertwined…
>>
>> Cheers,
>>
>> Greg.
>>
>> On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
>>
>>>
>>> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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
Re: [Discuss] Please have a look at the River Container
Posted by Greg Trasuk <tr...@stratuscom.com>.
Hi Dennis:
Discussion intertwined…
Cheers,
Greg.
On Feb 18, 2014, at 11:45 AM, Dennis Reedy <de...@gmail.com> wrote:
>
> On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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.
>
>> 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. 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).
To be clear, though, I’m not suggesting that river-container should be “the” way, just “a” way. 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.
>
>> For reasons that we’ve talked about endlessly, the Service Starter approach is unworkable (even without a potential race condition). That isn’t new - I remember when I started using Jini many years ago, I spent at least two days just bringing up Reggie. Then another two days getting a service running The “new-user” experience has been an issue since before we came to Apache. That’s why I wrote Harvester, that’s why Dennis created Rio, that’s why there were half a dozen containers created.
>> In fact I suspect that every developer who’s ever used Jini did their own container implementation, in one form or another.
>
> I'm not sure this is the case at all. Some did yes, most took advantage of what others had already written.
>
> Regards
>
> Dennis
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 18, 2014, at 1113AM, Greg Trasuk <tr...@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.
> 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.
>
> 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 :)
> For reasons that we’ve talked about endlessly, the Service Starter approach is unworkable (even without a potential race condition). That isn’t new - I remember when I started using Jini many years ago, I spent at least two days just bringing up Reggie. Then another two days getting a service running The “new-user” experience has been an issue since before we came to Apache. That’s why I wrote Harvester, that’s why Dennis created Rio, that’s why there were half a dozen containers created.
> In fact I suspect that every developer who’s ever used Jini did their own container implementation, in one form or another.
I'm not sure this is the case at all. Some did yes, most took advantage of what others had already written.
Regards
Dennis
Re: [Discuss] Please have a look at the River Container
Posted by Greg Trasuk <tr...@stratuscom.com>.
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 ;-). 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?
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. For reasons that we’ve talked about endlessly, the Service Starter approach is unworkable (even without a potential race condition). That isn’t new - I remember when I started using Jini many years ago, I spent at least two days just bringing up Reggie. Then another two days getting a service running The “new-user” experience has been an issue since before we came to Apache. That’s why I wrote Harvester, that’s why Dennis created Rio, that’s why there were half a dozen containers created. In fact I suspect that every developer who’s ever used Jini did their own container implementation, in one form or another.
As a result, we are not attracting users (we can’t even point to a “first steps” example that works), and hence not attracting developers. In the board minutes, one of the Apache Directors commented (quite correctly), that it’s a long time (2011) since we’ve added a committer or PMC member.
Now, we’ve had discussions about changing the build system, modularizing it, etc, in hopes of attracting developers. I think those discussions miss the point. In my opinion, we don’t need a group of new developers messing around in the River source code (yet). What we need is new developers to use River in their daily work, to create SOA applications. Then we’ll find where the pain points are in River, and interested developers can fix them (probably becoming PMC members in the process). But right now, developers have a very difficult time adopting River, or even running a sample application.
This problem is more important than bugs or race conditions. Bugs and race conditions don’t even exist for users if users can’t use the code to begin with.
I’m fine with developing the container on Github if the community decides that’s the right decision, but in the meantime I’m going to argue hard for a better user experience.
Cheers,
Greg.
On Feb 18, 2014, at 10:30 AM, Dennis Reedy <de...@gmail.com> wrote:
>
> On Feb 18, 2014, at 1011AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
>>
>> By the way, inevitably this container will be compared to Rio and other containers, and someone will ask “Why didn’t you just use Rio (or ‘startnow', or Seven, etc)?” What can I say? I had a different itch to scratch. Rio includes quality-of-service handling that I didn’t need, and I wanted a container that had a similar deployment model to Tomcat, so I wrote it inside the Apache River project. People are also encouraged to look at Rio, and if the Rio group wants to contribute code to River, we should welcome them.
>
> I've offered before, River just has not (in the past) been welcoming. Right now, I dont think that either your project or Rio should be part of River. I'd prefer that we have a Related Projects page that includes pointers to River related projects. That might be easiest.
>
> Dennis
>
Re: [Discuss] Please have a look at the River Container
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 18, 2014, at 1011AM, Greg Trasuk <tr...@stratuscom.com> wrote:
>
> By the way, inevitably this container will be compared to Rio and other containers, and someone will ask “Why didn’t you just use Rio (or ‘startnow', or Seven, etc)?” What can I say? I had a different itch to scratch. Rio includes quality-of-service handling that I didn’t need, and I wanted a container that had a similar deployment model to Tomcat, so I wrote it inside the Apache River project. People are also encouraged to look at Rio, and if the Rio group wants to contribute code to River, we should welcome them.
I've offered before, River just has not (in the past) been welcoming. Right now, I dont think that either your project or Rio should be part of River. I'd prefer that we have a Related Projects page that includes pointers to River related projects. That might be easiest.
Dennis