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
>
>

Reply via email to