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 <[email protected]> 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 <[email protected] <javascript:;>>
Sent: 02/11/2016 05:31:26 pm
To: [email protected] <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 <
[email protected] <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



Reply via email to