Sounds reasonable. Would there be a release that was just this refactor?
Or would then next release be a step along the path of the secure IoT theme? Bryan On Thursday, November 10, 2016, Peter <j...@zeus.net.au> wrote: > Thinking about how to proceed with code and repo... > > * I want to bring code in from an existing git repo and keep commit > history (I'm the only committer). Branched off a recent version of River > trunk. > * We want to change to using a git repo for River. > * Start building maven style modules from the ground up, starting with > JERI at low level. > * Separate out the qa test suite (integration tests), which is an ant > build that only depends on jars from river build. > * Where should jtreg test suite ( unit and regression tests) go? Maybe > with each relevant module? > * junit tests with appropriate module... > > Thoughts / suggestions? > > Regards, > > Peter. > > Sent from my Samsung device. > > Include original message > ---- Original message ---- > From: Peter <j...@zeus.net.au <javascript:;>> > Sent: 06/11/2016 08:23:06 pm > To: dev@river.apache.org <javascript:;> > Subject: Re: River revamp > > Yes same pattern, some details are different for security reasons, > additional support is required for lower level protocols as object > endpoints. > > Also, for example, devices were on a 6LowPAN network, different types of > devices would subscribe to different multicast groups, to minimise their > responses, since some devices may rely on battery power, we don't want > them to announce their presence or respond unnecessarily as that wastes > power. > > There are a number of new IoT protocols being developed, I think we'll > need to provide some support for some to start with. > > AMQP is another interesting protocol. > > On the discovery side, in order to make a connection, the multicast > response will need to contain the application layer name, transport > layer name, contact address and port, eg: MQTT, TCP, IP address:port. > Typically the nework layer will define the method of multicast. > > Cheers, > > Peter. > > On 6/11/2016 1:05 PM, Niclas Hedhman wrote: > > Ok, so this is more or less classic "surrogate" setup with JINI, right, > > with some additional SEC stuff, right? > > > > And that is a cool way to achieve interoperability with smaller devices > > without ability to run a JVM, especially the original > dream where devices > > don't know about each other ahead of time (except by some interface) > > > > I also see value where "IoT Service" doesn't bother with "Service > > Registrar" in the "Jini sense" and the "IoT Device" only participate in > > "Discovery" and then get a secure/trusted channel, onto which a > > light-weight protocol, such as MQTT or CoAP, can be funneled in either > > direction. > > > > > > > > On Sat, Nov 5, 2016 at 2:26 PM, Peter<j...@zeus.net.au <javascript:;> > > wrote: > > > >> Hmm lets try Ascii, hope line wrapping doesn't wreck it. > >> > >> > >> |<----------------------| Multicast request > >> Multicast | | > >> response |---------------------->| Connection& auth > >> | | to discovered address > >> RPCSEC_GSS |<----------------------| > >> auth |---------------------->| RPCSEC_GSS Auth > >> | | success, request > >> | | bytes containing > >> | | service proxy > >> | Register service | > >> | proxy& attributes |------------------ > ->| Registration > >> | Mange reg lease |<-------------------| > >> | | | > >> | | Match > >> |<-----------------| Lookup > >> | | > >> |----------------->| > >> | | | > >> | Authenticate Iot Service > >> | | | > >> | with bootstrap proxy > >> | | | > >> | Grant permission to download > >> | Auth client |<---------------- > ----------------------| > >> and deserialize service proxy. > >> | Return service proxy |----------------------------- > >> --------->| > >> | | | > >> | Prepare service proxy > >> |<------------------------------------------ > --------------------| > >> execute RPC function call > >> Function |------------------------------------------- > ------------------->| > >> with constraints > >> | | | > >> | > >> IoT Device IoT Service Service Registrar > >> Client > >> > >> > >> > >> > >> On 5/11/2016 3:48 PM, Peter 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 <javascript:;> > > 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 <javascript:;>> > >>>>> Sent: 03/11/2016 05:37:45 pm > >>>>> To: dev@river.apache.org <javascript:;> > >>>>> Subject: Re: River revamp > >>>>> > >>>>> A small footprint implementation of Jini's > lookup service written in C, > >>>>> fully JCK compliant. > >>>>> http://www.psinapticcom/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 > <javascript:;>> 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 <javascript:;>> > >>>>>> Sent: 03/11/2016 12:39:33 pm > >>>>>> To: dev@river.apache.org <javascript:;> > >>>>>> 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 > <javascript:;>> > >>>>>> 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 > <javascript:;>> 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:;> > <javascript:;>> > >>>>>>>>> Sent: 02/11/2016 05:31:26 pm > >>>>>>>>> To: dev@river.apache.org <javascript:;><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:;><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 > >>>>>> > >>>>>> > >>>>>> > > > > >
