Thinking about C and power constrained devices, how about the following: * Write an ONC RPC java compiler, to create java code (instead of C) client stubs.
* Provide support for TLS and constraints. * Provide an IPv6 constrained device announcement (C) and discovery (Java) utilities. Create a standard so other languages can be supported by others. * Write a java utility and service that manages proxies, registers discovered constrained devices with a lookup service and manages it's lease. This utility can generate attributes (from Configuration) and provide a bootstrap proxy (service) to allow clients to authenticate and obtain the smart proxy used to communicate directly with the device. * Provide an interface for clients to notify the utility service when a device is down. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Zsolt Kúti <la.ti...@gmail.com> Sent: 03/11/2016 05:37:45 pm To: dev@river.apache.org Subject: Re: River revamp A small footprint implementation of Jini's lookup service written in C, fully JCK compliant. http://www.psinaptic.com/link_files/PsiNapticTelematics.pdf A few years ago being involved in developing a streelighting management system I tried to access them to no avail. On Thu, Nov 3, 2016 at 8:09 AM, Peter <j...@zeus.net.au> wrote: > 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 > >
