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<j...@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<tras...@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<j...@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<tras...@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<p...@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:
...
