AW: Introduction of WebI2C and WebGPIO

Dear colleagues,

I would like to pick this discussion up in the next WoT IG TF-AP call, which is this Wednesday 15h CEST.
If there is interest, I can allocate an agenda topic for it.

It would be very good to also list the relevant existing API approaches for our tech landscape.

Best regards,
Johannes

> -----Ursprüngliche Nachricht-----
> Von: Satoru Takagi [mailto:sa-takagi@kddi.com]
> Gesendet: Donnerstag, 15. Oktober 2015 09:19
> An: waldron.rick@gmail.com
> Cc: public-device-apis@w3.org; public-wot-ig@w3.org; public-browserobo@w3.org
> Betreff: Re: Introduction of WebI2C and WebGPIO
> 
> Rick san,
> 
> Thank you for reviewing. I have added some issues to the spec.
> 
> In the MozOpenHard project, after implementing such APIs on the developed
> board computer, applications of some restrictive fields was made as
> experiments, and the demonstration etc. have been carried out.
> 
> Some of issues which you pointed out have been identified in those experiment.
> Of course, there must be many issues on which we have not been found yet.
> 
> Well, such API standardization will be advanced in the future. However, since
> it has not come to the time yet now, we are working as a project of a
> community. Of course, specs are still needed. And these specs will become a
> springboard for discussion of what may be standardized in the future.
> 
> Regards,
> 
> Satoru
> 
> >
> > 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
> >
> > >
> > >
> >
> >
> >
> 
> ----------------------------------------------------
>           Hello, New World.
>     五感を揺さぶる新体験を、すべての人に。
>       http://www.au.kddi.com/hello/

> ----------------------------------------------------
> Satoru Takagi (高木 悟)
> 
> W3C AC Representative, SVG2 Editor
> 
> KDDI CORPORATION, R&D Strategy Department, Technology Development Division
> Email:sa-takagi@kddi.com
> 
> この電子メール及び添付書類は名宛人のための秘密情報を含んで
> います。名宛人以外の方が受信された場合は、お手数をお掛けい
> たしますが、破棄をお願いいたします。

Received on Monday, 19 October 2015 11:19:15 UTC