Re: Programmatic and security models for IoT

On Thu, 2015-02-05 at 12:10 +0000, Tim Coote wrote:
> I’m also tracking js, but I’m not a huge fan of such poor typing - Flow seems to be an approach to addressing this.
> I like your anecdotes of adopting the technologies.
> 
> Thanks for those links. Like many that I’ve seen, there seems to be an emphasis on ‘happy path’ coding. IoT is a really hostile compute environment:
> - connections are very flakey


where connections are flaky I would expect something like DTN.
http://en.wikipedia.org/wiki/Delay-tolerant_networking



> - hardware drivers are poor quality
> - there is no release management
> - code runs unattended
> 
> And at the same time, I believe, most of the value arises when you combine the Things using the Internet and some Compute Nodes.
> 
> The economics of this are hard to spot: does the low entry cost of JS for devs trump the expected better robustness of a distributed E application? Or is the route to value through non-composition and bespoke apps per each device type, with expensive (>$20 each) devices (this seems to be the way that SmartThings is approaching the problem, although their approach of using eventual consistency is not good for controlling Things.)
> 
> Tim
> > SES (Secure EcmaScript) seems more promising, to me.
> > 
> > http://code.google.com/p/es-lab/
> > 
> > Using ocap discipline in javascript is really quite nice, as I
> > recently (re?)discovered. I work with this clinical data warehouse
> > query system (https://www.i2b2.org/) that has html/css/js/ajax
> > plug-ins. I made a couple plug-ins by copying an existing plug-in and
> > tweaking it. I was having trouble managing simple typos, so I tried
> > typescript. Then I used typescript class stuff, with implementation
> > inheritance, to factor out some common code between two plug-ins. I
> > couldn't reconcile typescript modules with the i2b2 plug-in loader; I
> > had to edit the compiled output each time. I decided that wasn't worth
> > the bother and just started maintaining the javascript. I set it aside
> > for a few months and then came back to it and realized I had created a
> > monster.
> > 
> > Then I got a chance to start fresh on another plugin
> > (https://bitbucket.org/DanC/cohorttops ). My colleague had i2b2
> > running on his laptop, so I used ssh and a Makefile to push my code
> > over there for testing as I developed it. When he shut down for the
> > day, I finally came to my senses and realized that if I used ocap
> > discipline, I could unit test my code without the whole i2b2 app
> > server and database environment. So I factored out all the sources of
> > authority and set up doctest.js. Ah... so much nicer!
> > 
> > (Aside: I'm completely addicted to doctest; I'm starting to look at
> > moving on from python, and I started to enjoy scala a bit, but every
> > time I wrote a test description, I kept grumbling "why do I have to
> > write this twice: once in my test descriptions and once in my
> > documentation?" doctest and E's updoc are pretty much the same idea.
> > http://doctestjs.org/ applies the same technique to JavaScript.
> > Yummy.)
> > 
> > Not only that, but the same style of code gets along great with the
> > flow static analyzer from some facebook engineers.
> > http://flowtype.org/
> > 
> > Back when the node.js platform was building, I kept hoping ocap
> > supporters would influence it, but I guess none of us found the time.
> > There's not much chance to influence the basic fs API and such now,
> > but it's still feasible to get a lot of benefit from ocap discipline
> > in javascript, both on the server side and the browser side.
> > 
> > And now IoT is an emerging thing, and they're going after developers
> > via javascript...
> > 
> > First Look: Javascript Microcontrollers for Web Developers
> > February 4th, 2013 8:56 am
> > http://makezine.com/magazine/first-look-javascript-micro-controllers-for-web-developers/
> > 
> > "DeviceJS is a distributed system. " --
> > http://devicejs.org/blog/post/how-it-works
> > 
> > IoT is just screaming out for robust composition with capabilities and
> > promises. I think deploying SES in that context is pretty promising.
> > 
> > 
> > -- 
> > Dan Connolly
> > http://www.madmode.com/
> > _______________________________________________
> > cap-talk mailing list
> > [email protected]
> > http://www.eros-os.org/mailman/listinfo/cap-talk
> 
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk




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