No png arrived. On Sat, Nov 5, 2016 at 1:48 PM, Peter <j...@zeus.net.au> wrote:
> Ok, will come back to the ascii art, I'll first attempt to attach a png. > > There's an existing Java RPC implementation LGPL, with a maven build tag > => oncrpc4j-2.6.0 > > https://github.com/dCache/oncrpc4j > > The implementation above supports /RPCSEC_GSS/ for security, although > there's a client side bug at present, but fixing it will be a lot less work > than reimplimenting it. > > Basically RPC is the C equivalent of Java RMI. > > Cheers, > > Peter. > > > On 5/11/2016 10:32 AM, Niclas Hedhman wrote: > >> 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
