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