Re: Introduction of WebI2C and WebGPIO

On Wed, Oct 14, 2015 at 12:41 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.  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.
>

Dave, thanks for this—I was having a hard time figuring out where to even
start with a response. From what I can tell, the two APIs being presented
are a drastic departure from emerging and defacto standards. I've seen this
before from the B2G team at Mozilla: some scenario solving for a specific
team's purpose, produce a "specification" and then expect W3 to immediately
adopt it for development. This same problem motivated the start of the
Generic Sensor API. These two specification documents ignore the body of
work that's been building since 2012. There is something of a "defacto"
standard that I've been tracking: https://github.com/rwaldron/io-plugins That
began as a protocol-specific API, but has evolved to simply describe
semantics of generic API, where implementation details can be independent,
as long as the observable semantics are correct.

A cursory read through of the shared documents reveals designs that don't
represent the sort of usage that would reflect reality (or that should be
encouraged). Some specific notes:

- Why is there read8 and read16 methods? How does read16 know the bit order
of the register it's requesting from, ie. LSB first, MSB first? What about
any other size? 20-bit, 24-bit, 32-bit...? There are devices (MPL3115A2)
that produce 20-bit values that are stored and read as [MSB, CSB, LSB] and
others (ADXL345) that produce 16-bit values that are stored and read as
[LSB, MSB]

- In practice, programs are unlikely to take one reading from an INPUT and
be done. Yes, that will happen, but it's far more common to set up a
"continuous read" of some input, with some kind of handler attached, which
receives the read data each time it's available. The Promise design is only
appropriate for one-shot reading, and shouldn't be the focus of the API's
design.

These issues lead me to believe that the authors haven't put these API
designs through any real use case analysis. I suggest actually building
something non-trivial with this API before presenting it for
standardization.

Non-API issues to consider: there is an inherent _danger_ in exposing
"generic" I2C and GPIO in a "browser". Please consider the following
scenarios:

If I grant access to two web apps that want "GPIO" and "I2C" permission
(what does that even mean to a user??), which one gets to control the
hardware? What if this is some kind of medical software and one app sets a
pin LOW that is currently HIGH for a life support machine (contrived, but
consider it)? What if it's a drone and the second app shuts off the motors
mid flight?


There is much to discuss here, but I only have a limited amount of time to
dedicate to a review at the moment.

Rick

>
>