Sent from my Samsung device. Include original message ---- Original message ---- From: Patricia Shanahan <p...@acm.org> Sent: 03/11/2016 12:41:54 am To: dev@river.apache.org Subject: Re: River revamp
I think for this to work it is necessary to find out where IoT people hang out, and discuss it there. Do they already have a plan for a secure framework? As a potential IoT user I'm looking for two things: 1. Security. 2. Server independence. I don't want my thermostat to stop working if a server I don't control goes down or is taken out of service for any reason. I think River may be a good basis for those features. On 11/2/2016 7:22 AM, Bryan Thompson wrote: > I look at this as open source for secure IoT. The need for security in IoT > has been aptly demonstrated by recent DDOS attaches based on compromised > devices. > > I do feel that interop is critical to success here. > > Do we have any lurkers from the IoT manufacturing space here? People or > companies willing to invest time and resources for a secure IOT platform? > > Bryan > > On Wednesday, November 2, 2016, Peter <j...@zeus.net.au> wrote: > >> Utilising most of the existing discovery code, we could use ipv6 >> multicast, for an exported remote object (service) >> >> Then create a new class called RemoteDiscovery to discover a service >> dynamically, based on a name >> >> So you export a service and it becomes dynamically discoverable. >> >> It's not going to step on any Jini discovery lookup stuff and it's going >> to be easily deployed by new users. >> >> Then once users realise there's more on offer they can take advantage as >> their understanding develops. >> >> Cheers, >> >> Peter. >> >> Sent from my Samsung device. >> >> Include original message >> ---- Original message ---- >> From: Niclas Hedhman <nic...@hedhman.org <javascript:;>> >> Sent: 02/11/2016 05:31:26 pm >> To: dev@river.apache.org <javascript:;> >> Subject: Re: River revamp >> >> To put a bit more meat on Peter's condensed list... >> >> I put forward a proposal to sever the ties between River and Jini itself, >> and instead re-focus River to be a a secured network transport, with >> optional discovery. Starting point is of course the JERI >> module and Peter's >> work to secure this transport, but in the longer term look at alternative >> transport formats and eventually bindings to other >> languages, which I think >> will be the major hurdle for long term acceptance (no one is Java-only >> nowadays). >> >> Jini's services, Reggie and so on, carries a lot of negative connotation >> among people who were around back then, and except for where it has been >> adopted, I doubt that there will be any new uptake, so instead of making >> Jini (and its specs) the focal point of River, make it >> to "Examples of what >> River can be used for". >> >> Another example of what can be done with River could eventually include >> connectors for popular platforms, such as Zookeeper, which could open >> avenues for new blood coming to River. >> >> Concrete things; Apache Karaf is also a very small >> community, yet they have >> managed to put together a very exciting website, and I think River >> community could "borrow" a lot of that work, making itself more appealing, >> promoting the new focus. I don't think much coding is needed to get this >> going, but packaging might be "fixed" to make consumption of the core >> functionality as easy as possible, preferably easier than that. >> >> Once that is up-and-running starting the "reach out" to other projects, >> individuals and press releases. >> >> >> I hope that this will inspire some to more action. >> >> Niclas >> >> >> >> >> >> On Wed, Nov 2, 2016 at 2:25 PM, Peter Firmstone < >> peter.firmst...@zeus.net.au <javascript:;> >>> wrote: >> >>> A discussion recently ignited on river private >> about revamping the project. >>> >>> For the benefit of the wider developer community can we restate the >>> suggestions here, feel free to reword, correct, reject or >> suggest It was >>> along the lines of: >>> >>> * Website revamp >>> * Remove Jini focus, with a historical section... >>> * Focus on new security features. >>> * Make getting started simple, with just the bare >> bones basics, Extensible >>> remote invocation with secure serialization. >>> * Services, Javaspaces etc, become examples of what can be done with >>> River, not what River is. >>> >>> Regards, >>> >>> Peter. >>> >>> >>> >>> Sent from my Samsung device. >>> >>> >> >> >> >> -- >> Niclas Hedhman, Software Developer >> http://zest.apache.org - New Energy for Java >> >> >