You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2016/04/06 12:54:26 UTC
Re: The future thing
Thanks Tom,
I don't think the River community is ready to abandon the 2.2 branch
just yet.
It doesn't look like anyone's about to volunteer to spin another 3.0.0
release just yet either. Concerns remain about River 3.0 being ready
for prime time, in any case we're only set up for source releases at
present, so it would seem best to leave trunk as it is for people to
check out, build and test until confidence improves. In any case
there's a 2.2 series release to tide people over.
Can others on the list tell us more about where they think River's
future development path should be?
What other repetitive tasks do people do now that we could develop tools
for?
Regards,
Peter.
On 2/03/2016 7:05 AM, Tom Hobbs wrote:
>> Can you tell us more about the tools River requires for deployment inside
> docker containers?
>
> The answer could be "nothing to do", but anyway it is a job for Future
> Tom. I'm sure he'll be happy to share when he figures it out. :-) In
> fact was intending to commit the Dockerfiles when I get them sorted out.
>
> +1 on setting goals. Clear goals and direction are a must. Last time I
> looked (ages ago!) there is /nothing/ on our backlog that looked fun (to
> me). A roadmap and unscoped (?) backlog items might help to change that.
>
> Good luck on securing services over the net - and I mean that seriously.
> Since my previous email, I've got half a use case bubbling away in the back
> my mind which might just find it useful.
>
> Talking about Git. What do people thing about deploying 3.0 as the fresh
> new source in (Apache's) Git and just locking/deprecating/abandoning
> whatever is in SVN?
>
>
> On Mon, Feb 29, 2016 at 12:04 PM, Peter<ji...@zeus.net.au> wrote:
>
>> Can you tell us more about the tools River requires for deployment inside
>> docker containers?
>>
>> River needs to establish goals and it needs committers willing to work
>> towards those goals, at the moment we don't have little of either, so
>> establishing some may help the project survive.
>>
>> I'm working on a secure version of River, forked from River trunk, for use
>> on either side of the firewall, I'm tempted to consider removal of all
>> dependencies on rmi code, but presently it is backward compatible with
>> River. I think most people misunderstand the concept of River on the web,
>> or the internet, it's not something that would run from within a web
>> browser like a plugin, it's just a way for programs to send messages to
>> each other, peer to peer, globally, without requiring setting up web
>> servers and clients, it's not the sever -> client / content provider&
>> consumer model. It has a lot more in common with the IoT model.
>>
>> In any case, securing river isn't that big a deal, it's somewhat easier to
>> understand as ProxyTrust has been deprecated and there are performance
>> improvements, but don't take my word for it, go see for yourself.
>>
>> https://github.com/pfirmstone/river-internet
>>
>> Regards,
>>
>> Peter
>>
>>
>>
>> On 28/02/2016 12:10 AM, Tom Hobbs wrote:
>>
>>> +1 on making it easy. Spark has their "here's how you can use Spark to
>>> stream a word count program" example, as far as I'm aware River doesn't
>>> have anything similar.
>>>
>>> +1 on the Docker mention, I've been doing lots of Docker recently with
>>> Consul as a service discovery mechanism, I think River would really
>>> benefit
>>> from Docker-isation. Both in terms of running Reggie, Outrigger etc
>>> inside
>>> containers, and also using Reggie et al to orchestrate containers. In
>>> fact, that's on my list of things to do.
>>>
>>> Like Greg, I see River being used behind the firewall. I'm intending on
>>> using it for a prototype something new I'm cooking up right now. I get
>>> your point about the network security never being guaranteed, either
>>> through malice or poor code, but for my own use cases, if someone is
>>> introducing deliberate RMI based security problems on my network then I
>>> have far bigger issues than my River services. I personally have no
>>> appetite for River-on-the-web, but good luck to anyone who wants to go for
>>> it.
>>>
>>>
>>>
>>> On Sat, Feb 27, 2016 at 11:53 AM, Peter<ji...@zeus.net.au> wrote:
>>>
>>> Good, we can focus on making development easier.
>>>> What tool do you need to make development easier?
>>>>
>>>> Don't forget the 4th fallacy of distributed computing, the network is
>>>> secure. Many recent security breaches have been via inadequate security
>>>> behind the firewall. I don't know your situation but not everyones will
>>>> be
>>>> the same. With all the recent serialization rmi security scares, we
>>>> could
>>>> pick up some market share instead of other more in vogue rpc frameworks
>>>> capturing it all.
>>>>
>>>> I did some work on a security manager for generating policy files, but it
>>>> was deleted at some point, before I got back to it, I made
>>>> CombinerSecurityManager extensible so it can be made to do the same.
>>>> Another tool that would be useful is one to generate preferred class
>>>> lists.
>>>>
>>>> Regards,
>>>>
>>>> Peter.
>>>>
>>>> Sent from my Samsung device.
>>>>
>>>> Include original message
>>>> ---- Original message ----
>>>> From: Greg Trasuk<tr...@stratuscom.com>
>>>> Sent: 27/02/2016 01:54:15 pm
>>>> To:dev@river.apache.org
>>>> Subject: Re: The future thing
>>>>
>>>>
>>>>
>>>> My vote - service integration in the cloud/data centre. I look at the
>>>> convolutions that people are going through to get service discovery working
>>>> in a Docker environment (e.g
>>>>
>>>> https://www.digitalocean.com/community/tutorials/the-docker-ecosystem-service-discovery-and-distributed-configuration-stores
>>>> ), and I think that Jini has solved this problem already. The dynamic
>>>> discovery and zero-configuration nature of Jini, not to mention the
>>>> inherent fault-tolerance that goes along with leasing, etc, makes Jini
>>>> perfectly suited to a dynamically-scalable environment. We just haven’t
>>>> made it easy to get started. Also, in the past, people were often left
>>>> with the impression that Jini was too complex. I think that people have
>>>> come around to the idea that the problem-space for distributed computing is
>>>> complex, so the solution-space is necessarily complex as well.
>>>>
>>>>
>>>>
>>>> So, what I’d like to see is a solid focus on making it easy to write
>>>> micro-services and clients to micro-services using Jini. I’ll be clear
>>>> here and say I’m not talking about user-facing client-side integration.
>>>> I’m talking about integrating micro-services behind the firewall, where the
>>>> ‘clients’ are either other services behind the firewall or web applications
>>>> that provide the internet-facing service as http-based RESTful services.
>>>>
>>>>
>>>> We should work on tools, examples, and frameworks that make it
>>>> demonstrably easier to write applications using River.
>>>>
>>>> There’s my $0.02
>>>>
>>>> Cheers,
>>>>
>>>> Greg Trasuk
>>>>
>>>> On Feb 26, 2016, at 6:47 PM, Peter<ji...@zeus.net.au> wrote:
>>>>> I'll reply to these later, I'm on the road atm.
>>>>>
>>>>> In the mean time, what do you, our community of developers envision for
>>>>> River's future?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Sent from my Samsung device.
>>>>>
>>>>> Include original message
>>>>> ---- Original message ----
>>>>> From: Greg Trasuk<tr...@stratuscom.com>
>>>>> Sent: 26/02/2016 01:01:14 am
>>>>> To:dev@river.apacheorg
>>>>> Subject: Re: The future thing
>>>>>
>>>>>
>>>>> I think it’s difficult to talk about future features without context.
>>>>> So it would be helpful if we could express in a great level of detail what
>>>>> exactly we see people doing with River. Perhaps even build a
>>>>> proof-of-concept demonstration and use that to drive any changes to River.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Greg Trasuk
>>>>>
>>>>> On Feb 25, 2016, at 9:33 AM, Patricia Shanahan<pa...@acm.org> wrote:
>>>>>> Thanks for getting this started
>>>>>>
>>>>>> I think you have a high level vision of where you see River going in
>>>>>> the future. It might be useful to state it here. The costs and benefits of
>>>>>> changes are best evaluated in that sort of context.
>>>>>>
>>>>>> On 2/25/2016 3:52 AM, Peter Firmstone wrote:
>>>>>>
>>>>>>> While we're waiting for people to review River 3.0's Release
>>>>>>> artifacts...
>>>>>>>
>>>>>>> I've posted some of my more contraversial work on River security and
>>>>>>> ipv6 global discovery (internet announcement protocol) on github.
>>>>>>> The river community is free to cherry pick the code if it wants. I
>>>>>>> would have much preferred to have developed it collaboratively,
>>>>>>> there's room for improvement.
>>>>>>>
>>>>>>> Features:
>>>>>>>
>>>>>> ...
>>>>>>
Re: The future thing
Posted by Patricia Shanahan <pa...@acm.org>.
The ability to spin releases is a key aspect of being a viable project.
If we can't do that, I need to raise it as an issue in my next board
report. The problem of divergence between the last release and the trunk
is only going to get worse with time.
On 4/6/2016 3:54 AM, Peter wrote:
> Thanks Tom,
>
> I don't think the River community is ready to abandon the 2.2 branch
> just yet.
>
> It doesn't look like anyone's about to volunteer to spin another 3.0.0
> release just yet either. Concerns remain about River 3.0 being ready
> for prime time, in any case we're only set up for source releases at
> present, so it would seem best to leave trunk as it is for people to
> check out, build and test until confidence improves. In any case
> there's a 2.2 series release to tide people over.
>
> Can others on the list tell us more about where they think River's
> future development path should be?
>
> What other repetitive tasks do people do now that we could develop tools
> for?
>
> Regards,
>
> Peter.
>
> On 2/03/2016 7:05 AM, Tom Hobbs wrote:
>>> Can you tell us more about the tools River requires for deployment
>>> inside
>> docker containers?
>>
>> The answer could be "nothing to do", but anyway it is a job for Future
>> Tom. I'm sure he'll be happy to share when he figures it out. :-) In
>> fact was intending to commit the Dockerfiles when I get them sorted out.
>>
>> +1 on setting goals. Clear goals and direction are a must. Last time I
>> looked (ages ago!) there is /nothing/ on our backlog that looked fun (to
>> me). A roadmap and unscoped (?) backlog items might help to change that.
>>
>> Good luck on securing services over the net - and I mean that seriously.
>> Since my previous email, I've got half a use case bubbling away in the
>> back
>> my mind which might just find it useful.
>>
>> Talking about Git. What do people thing about deploying 3.0 as the fresh
>> new source in (Apache's) Git and just locking/deprecating/abandoning
>> whatever is in SVN?
>>
>>
>> On Mon, Feb 29, 2016 at 12:04 PM, Peter<ji...@zeus.net.au> wrote:
>>
>>> Can you tell us more about the tools River requires for deployment
>>> inside
>>> docker containers?
>>>
>>> River needs to establish goals and it needs committers willing to work
>>> towards those goals, at the moment we don't have little of either, so
>>> establishing some may help the project survive.
>>>
>>> I'm working on a secure version of River, forked from River trunk,
>>> for use
>>> on either side of the firewall, I'm tempted to consider removal of all
>>> dependencies on rmi code, but presently it is backward compatible with
>>> River. I think most people misunderstand the concept of River on the
>>> web,
>>> or the internet, it's not something that would run from within a web
>>> browser like a plugin, it's just a way for programs to send messages to
>>> each other, peer to peer, globally, without requiring setting up web
>>> servers and clients, it's not the sever -> client / content provider&
>>> consumer model. It has a lot more in common with the IoT model.
>>>
>>> In any case, securing river isn't that big a deal, it's somewhat
>>> easier to
>>> understand as ProxyTrust has been deprecated and there are performance
>>> improvements, but don't take my word for it, go see for yourself.
>>>
>>> https://github.com/pfirmstone/river-internet
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>>
>>>
>>> On 28/02/2016 12:10 AM, Tom Hobbs wrote:
>>>
>>>> +1 on making it easy. Spark has their "here's how you can use Spark to
>>>> stream a word count program" example, as far as I'm aware River doesn't
>>>> have anything similar.
>>>>
>>>> +1 on the Docker mention, I've been doing lots of Docker recently with
>>>> Consul as a service discovery mechanism, I think River would really
>>>> benefit
>>>> from Docker-isation. Both in terms of running Reggie, Outrigger etc
>>>> inside
>>>> containers, and also using Reggie et al to orchestrate containers. In
>>>> fact, that's on my list of things to do.
>>>>
>>>> Like Greg, I see River being used behind the firewall. I'm
>>>> intending on
>>>> using it for a prototype something new I'm cooking up right now. I get
>>>> your point about the network security never being guaranteed, either
>>>> through malice or poor code, but for my own use cases, if someone is
>>>> introducing deliberate RMI based security problems on my network then I
>>>> have far bigger issues than my River services. I personally have no
>>>> appetite for River-on-the-web, but good luck to anyone who wants to
>>>> go for
>>>> it.
>>>>
>>>>
>>>>
>>>> On Sat, Feb 27, 2016 at 11:53 AM, Peter<ji...@zeus.net.au> wrote:
>>>>
>>>> Good, we can focus on making development easier.
>>>>> What tool do you need to make development easier?
>>>>>
>>>>> Don't forget the 4th fallacy of distributed computing, the network is
>>>>> secure. Many recent security breaches have been via inadequate
>>>>> security
>>>>> behind the firewall. I don't know your situation but not everyones
>>>>> will
>>>>> be
>>>>> the same. With all the recent serialization rmi security scares, we
>>>>> could
>>>>> pick up some market share instead of other more in vogue rpc
>>>>> frameworks
>>>>> capturing it all.
>>>>>
>>>>> I did some work on a security manager for generating policy files,
>>>>> but it
>>>>> was deleted at some point, before I got back to it, I made
>>>>> CombinerSecurityManager extensible so it can be made to do the same.
>>>>> Another tool that would be useful is one to generate preferred class
>>>>> lists.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Sent from my Samsung device.
>>>>>
>>>>> Include original message
>>>>> ---- Original message ----
>>>>> From: Greg Trasuk<tr...@stratuscom.com>
>>>>> Sent: 27/02/2016 01:54:15 pm
>>>>> To:dev@river.apache.org
>>>>> Subject: Re: The future thing
>>>>>
>>>>>
>>>>>
>>>>> My vote - service integration in the cloud/data centre. I look at the
>>>>> convolutions that people are going through to get service discovery
>>>>> working
>>>>> in a Docker environment (e.g
>>>>>
>>>>> https://www.digitalocean.com/community/tutorials/the-docker-ecosystem-service-discovery-and-distributed-configuration-stores
>>>>>
>>>>> ), and I think that Jini has solved this problem already. The dynamic
>>>>> discovery and zero-configuration nature of Jini, not to mention the
>>>>> inherent fault-tolerance that goes along with leasing, etc, makes Jini
>>>>> perfectly suited to a dynamically-scalable environment. We just
>>>>> haven’t
>>>>> made it easy to get started. Also, in the past, people were often
>>>>> left
>>>>> with the impression that Jini was too complex. I think that people
>>>>> have
>>>>> come around to the idea that the problem-space for distributed
>>>>> computing is
>>>>> complex, so the solution-space is necessarily complex as well.
>>>>>
>>>>>
>>>>>
>>>>> So, what I’d like to see is a solid focus on making it easy to write
>>>>> micro-services and clients to micro-services using Jini. I’ll be
>>>>> clear
>>>>> here and say I’m not talking about user-facing client-side
>>>>> integration.
>>>>> I’m talking about integrating micro-services behind the firewall,
>>>>> where the
>>>>> ‘clients’ are either other services behind the firewall or web
>>>>> applications
>>>>> that provide the internet-facing service as http-based RESTful
>>>>> services.
>>>>>
>>>>>
>>>>> We should work on tools, examples, and frameworks that make it
>>>>> demonstrably easier to write applications using River.
>>>>>
>>>>> There’s my $0.02
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Greg Trasuk
>>>>>
>>>>> On Feb 26, 2016, at 6:47 PM, Peter<ji...@zeus.net.au> wrote:
>>>>>> I'll reply to these later, I'm on the road atm.
>>>>>>
>>>>>> In the mean time, what do you, our community of developers
>>>>>> envision for
>>>>>> River's future?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Peter.
>>>>>>
>>>>>> Sent from my Samsung device.
>>>>>>
>>>>>> Include original message
>>>>>> ---- Original message ----
>>>>>> From: Greg Trasuk<tr...@stratuscom.com>
>>>>>> Sent: 26/02/2016 01:01:14 am
>>>>>> To:dev@river.apacheorg
>>>>>> Subject: Re: The future thing
>>>>>>
>>>>>>
>>>>>> I think it’s difficult to talk about future features without context.
>>>>>> So it would be helpful if we could express in a great level of
>>>>>> detail what
>>>>>> exactly we see people doing with River. Perhaps even build a
>>>>>> proof-of-concept demonstration and use that to drive any changes
>>>>>> to River.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Greg Trasuk
>>>>>>
>>>>>> On Feb 25, 2016, at 9:33 AM, Patricia Shanahan<pa...@acm.org>
>>>>>> wrote:
>>>>>>> Thanks for getting this started
>>>>>>>
>>>>>>> I think you have a high level vision of where you see River
>>>>>>> going in
>>>>>>> the future. It might be useful to state it here. The costs and
>>>>>>> benefits of
>>>>>>> changes are best evaluated in that sort of context.
>>>>>>>
>>>>>>> On 2/25/2016 3:52 AM, Peter Firmstone wrote:
>>>>>>>
>>>>>>>> While we're waiting for people to review River 3.0's Release
>>>>>>>> artifacts...
>>>>>>>>
>>>>>>>> I've posted some of my more contraversial work on River
>>>>>>>> security and
>>>>>>>> ipv6 global discovery (internet announcement protocol) on
>>>>>>>> github.
>>>>>>>> The river community is free to cherry pick the code if it
>>>>>>>> wants. I
>>>>>>>> would have much preferred to have developed it collaboratively,
>>>>>>>> there's room for improvement.
>>>>>>>>
>>>>>>>> Features:
>>>>>>>>
>>>>>>> ...
>>>>>>>
>