"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