river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: River revamp
Date Sat, 05 Nov 2016 00:04:32 GMT
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.tinca@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 <jini@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 <niclas@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 <pats@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 <jini@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 <niclas@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.firmstone@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 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message