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: >> ... > >
