Re: Introduction of WebI2C and WebGPIO

> 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.  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.  An alternative is to run a native app that acts as an embedded server and allows web pages to use Web Sockets to indirectly access IoT devices via other protocols such as MQTT and CoAP.

I would be most grateful if you can provide further background as to the architecture you are using and why you chose it compared to other choices such as those presented above.

Best regards,
—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>