Sorry, I get the feeling that too much detail thinking is still in your head. Hard for me to follow your thought process. A simple picture (ascii art would do) would go a long way...
Niclas On Sat, Nov 5, 2016 at 8:04 AM, Peter <j...@zeus.net.au> wrote: > 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 > > > > > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
