Re: Programmatic and security models for IoT

Tom Van Cutsem <[email protected]> Sun, 8 Feb 2015 20:04:52 +0100
Newsgroups gmane.comp.capabilities.general
Message-ID <CAKDfNj9iOyHLJa+2xJvCsW8_egZybUEjW9_1gxpHBKN+aCGrmA@mail.gmail.com>
2015-02-06 16:21 GMT+01:00 Tim Coote <[email protected]>:

>
> Actually, the flaky comms was something that I considered well addressed
> by E’s distributed computing model (
> http://www.skyhunter.com/marcs/ewalnut.html#SEC18), which, to my mind,
> puts about the right amount of awareness of the potential failures into the
> mind of the developer (ie she has to consider failure of any remote
> access), while not exposing the very difficult challenges of unknown
> failures (eg the work of Waterken and COVR assure less fragile systems.)
>

Hi Tim,

Have you looked at AmbientTalk? (website: <
https://code.google.com/p/ambienttalk/>, paper: <
http://soft.vub.ac.be/Publications/2014/vub-soft-tr-14-06.pdf>)

AmbientTalk is a language building entirely on the concepts of E, but
tailored for precisely the kind of scenarios you have  in mind. When we
designed it back in 2005-2006, "IoT" was in its infancy and the fashion
buzzword of the day was "Ambient intelligence", hence the language's name
(today I might have called it ThingTalk ;-)

More to the point, AmbientTalk changes the failure handling semantics of E
to be more appropriate for communication over flaky wireless communication
links. In AmbientTalk, a far reference will not immediately break upon a
disconnection, instead buffering and retransmitting eventually sent
messages until the receiver is available again. This kind of adaptive
buffering is often the default behavior one would expect, letting
applications gracefully tolerate intermittent network connections without
additional programmer effort.

Of course, sometimes one does want to respond to more permanent failure.
Ambienttalk provides plenty of mechanism to deal with that too (timeouts on
messages, leased far references; which expire and break after being
disconnected for a given period of time).

My thesis work specifically introduced a series of far reference-like
abstractions called "ambient references" which combines the concept of an E
eventual reference with the concept of service discovery, allowing you to
e.g. write:

def p = ambient Printer;

which asynchronously launches a discovery request for a service exported as
a "Printer" in the local network, and immediately binds p to what you might
call a promise to a far reference to a (to be discovered) printer object.
You can find more details than you'd like in my phd: <
http://prog.vub.ac.be/~tvcutsem/publications/phd_tom_van_cutsem.pdf>.

Ambient references make it easy to write little 5-line scripts that set up
the wiring between different services in the environment, which is exactly
the kind of thing one typically does in IoT settings.

All that said, AmbientTalk, like E-on-Java, was built as a Java
interpreter, and is unsuitable for large-scale development. In line with
the earlier comments, I would seriously consider using JavaScript as your
development platform: it's got the right event loop model, it's got
excellent Promise libraries, and with node.js it should be easy enough to
interface with external libraries to do stuff like service discovery.
Hopefully one day we'll have a platform like Dr. SES <
https://github.com/drses/ses> that combines all of that with water-tight
security.

Best of luck with your IoT platform,
Tom

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk