- From: Drasko DRASKOVIC <drasko.draskovic@gmail.com>
- Date: Wed, 14 Oct 2015 20:20:39 +0200
- 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 WebSocket. BR, Drasko
Received on Wednesday, 14 October 2015 18:21:09 UTC