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