- From: Drasko DRASKOVIC <drasko.draskovic@gmail.com>
- Date: Wed, 14 Oct 2015 11:44:28 +0200
- To: Satoru Takagi <sa-takagi@kddi.com>
- Cc: Futomi Hatano <futomi.hatano@newphoria.co.jp>, public-device-apis@w3.org, Public Web of Things IG <public-wot-ig@w3.org>, public-browserobo@w3.org, tobie@sensors.codespeaks.com
On Wed, Oct 14, 2015 at 11:11 AM, Satoru Takagi <sa-takagi@kddi.com> wrote: >> > I think you should take a look at WeIO (http://we-io.com), >> The site seems to be down. > Probably it is this. > http://we-io.net/ > > It seems to resemble tessel. > https://tessel.io/ WeIO has been around for two years now, and new Tessel (not produced yet, and radically different then Tessel 1) will resemble it in the sense of HW architecture, but not SW - Tessel does not have a server application nor particular APIs. > > We are interested in browser technologies in particular. > I seem to be worth researching the relations with them, at a viewpoint of delivering web > technologies to maker movement and reconsidering a role of server and client, If I understand correctly you would launch browser localy on the board and then use JS API to manipulate HW. In this case, browser will include what in WeIO is currently broken in two parts - Python server and HTTP clinet. User uses __client__ JS API (thus **from the browser**), to manipulate electronics, calling Arduino-similar functions: http://we-io.net/doc/jsAPI.html. I perfectly understand that your idea is different - it will be on-the-board browser to take the role of the Python server in WeIO case. I just wanted to draw your attention to an interesting existing use-case and API approach, which has similarity. BR, Drasko
Received on Wednesday, 14 October 2015 09:45:00 UTC