I've been conaidering that. It should be possible to implement service discovery in C, any serialized java bytes required for a proxy could be stored on the device.
So these devices are services, but not clients. Will respond with more soon Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Niclas Hedhman <nic...@hedhman.org> Sent: 03/11/2016 12:39:33 pm To: dev@river.apache.org Subject: Re: River revamp "IoT" is a term that for this discussion is a bit too wide. The "thermostat" runs with a kB-sized microcontroller and is struggling to get security features in at all, and the "home router" is typically (still) running from a 4-8MByte flash, which is impossible to even get a Java ME onto, so there is a lot of challenges when using "IoT" as a blanket term. So, I think a couple of concrete, do-able, use-cases need to be highlighted as examples, maybe a kind of "blue print" paper on how to do it with River. I totally agree that the "mothership" model is outrageous from a consumer's perspective, a nasty vendor lock-in, that all vendors are pushing for and all consumers/users need to fight the best we can. A very active home automation project is called "OpenHAB", a flurry of activity, connecting just about everything from your thermostat to your dog's toys. I have not looked closely at it, don't even know if it is a Java project as such, but it is one of the most active projects in the field of Home IoT. Cheers Niclas On Wed, Nov 2, 2016 at 10:41 PM, Patricia Shanahan <p...@acm.org> wrote: > 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 >>> >>> >>> >> -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
