Re: Introduction of WebI2C and WebGPIO

Satoru san, Futomi san,

I understand your goal of combining web programming with low latency. It will enable precise control of devices in many important use cases using highly reusable code and design patterns. I see a larger potential also.

In the bigger picture, it seems very worthwhile to be able to expose machine interfaces using common HTML code. This could enable the interface of something like a thermostat or lighting control to be discovered, rendered and processed using today’s tools of DOM and Javascript using familiar programming models.

 It also enables the integration of well known hypermedia controls to expose resources using the Web of Things interaction model through markup-based controls that can be processed by Javascript handlers to drive application state machines. In addition, a resource like Schema.org could be used to provide common semantics, again integrated using markup like microformats.

So the web browser doesn’t always need to run on the device. The device can still be a server that publishes the rich HTML document which enables the WoT interaction model between it and application clients that may or may not have screens.

Or if there is a suitable environment on the device, the script code may run directly on the hardware I/O.

Best regards,

Michael

On Oct 19, 2015, at 6:39 AM, 전종홍 <hollobit@etri.re.kr> wrote:

> Dear Satoru, 
> 
> Thanks for your information. 
> 
> Basically, I agree that we need to find some interfaces for controlling the hardware directly by web. 
> 
> But, I think there is a big clarification point. 
> 
> Your idea, browser based hardware access, should require “browser on every devices”.   
> As you know well, general browser is required many computing resources (memory, computing power). 
> Do you think many constrained devices can embed browser engines ?
> How many browser can support it for open source hardwares ? 
> 
> I think browser based model is not suitable for small limited devices. 
> So I think it would be better to consider small JS engine based model (similar with node.js) 
> (There are many hardware interface(GPIO, I2C) implementations which is base on node.js already) 
> 
> Best Regards,
> 
> — Jonathan Jeon 
> 
>> 2015. 10. 15., 오후 4:19, Satoru Takagi <sa-takagi@kddi.com> 작성:
>> 
>> 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 16:30:45 UTC