W3C home > Mailing lists > Public > public-wot-ig@w3.org > October 2015

Re: Introduction of WebI2C and WebGPIO

From: Drasko DRASKOVIC <drasko.draskovic@gmail.com>
Date: Wed, 14 Oct 2015 20:20:39 +0200
Message-ID: <CAEk6gTD32gcW45W77SeLy1+jhBiP2Oh-erKe1Smrhp+nis+dWg@mail.gmail.com>
To: Dave Raggett <dsr@w3.org>
Cc: Futomi Hatano <futomi.hatano@newphoria.co.jp>, Satoru Takagi <sa-takagi@kddi.com>, 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 6:39 PM, Dave Raggett <dsr@w3.org> wrote:
> On 14 Oct 2015, at 08:02, Futomi Hatano <futomi.hatano@newphoria.co.jp>
> wrote:
> The local-server architecture has a disadvantage.
> It is latency.
> If browsers implement GPIO/I2C API directly,
> the disadvantage would be solved.
> We need both of the architectures.
> Could you please clarify the scenario? To have a web browser, you would need
> a device like a smart phone or tablet with a display and sufficient memory
> and processing speed to run the browser.

Small observation - speed yes, but not necessarily display. You can
always access the GUI via remote X server. One `ssh -X` should do.

>  Do smart phones make use of GPIO
> and I2C, and if so, what is the need to access the device’s hardware at this
> low level?  Browsers already provide high level APIs for accessing
> capabilities such as the orientation, acceleration, geolocation, ambient
> brightness, microphone, camera, etc.
> A device like a Raspberry Pi has enough power to run NodeJS and WebSockets,
> as well as providing low level access to GPIO, SPI and I2C for interfacing
> to sensors and actuators. The device would be accessible via both HTTP and
> WebSockets. A browser would be able to load a web page via HTTP and then set
> up a WebSocket connection for asynchronous bidirectional JSON messaging.
> A device based upon a microcontroller would be more constrained. You would
> typically have a separate chip for the networking, e.g. W5100 Ethernet
> driver.  However, some chips include a general purpose microcontroller
> together with the networking hardware, e.g. the ESP8266 which embeds a WiFi
> module. TCP is possible, e.g. to support MQTT, but a UDP based solution may
> be preferable, e.g. to support CoAP.
> It is unlikely that browsers would support MQTT and CoAP for regular web
> pages,
> however, it is certainly practical to support these protocols via
> browser extensions, e.g. the Copper browser extension for Firefox, given
> that many browsers now offer direct access to TCP and UDP sockets from
> browser extensions.

While CoAP has a browser support only in Firefox currently (via
Copper), MQTT support is even easier - for example via lib like this
https://github.com/mqttjs/MQTT.js which can send MQTT messages via

Received on Wednesday, 14 October 2015 18:21:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:49 UTC