- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 May 2015 13:15:09 +0000
- To: public-device-apis@w3.org
> But IMO we also should consider reusing resp. taking input from the proposal for the APIs for scripts on a WoT device, e.g. to access the device's sensors. The purpose of the Generic Sensor API we're working on here is to devise a superclass and blueprint for concrete sensors to derive from. It seems that sensors accessed through HTTP are a perfect example of such a concrete sensor, or at least of a subclass of an abstract sensor constructor. Now, there's a bunch of things I'm not sure I understand in your proposal yet. A few questions come to mind: * Why expose both RPC (doAction) and REST-like (get, set) models (especially given the examples used for RPC seem to only do state changes)? * Are "things" much more than sensors? * If so, are they much less than servers? * Is a native JS API worth building, or is it just sugar for a combination of [WebSockets][1] and [fetch][2]? * How much of the actual capacities of the "thing" is know beforehand vs. shared as part of the initial handshake that still needs to be defined by the task force? [1]: http://dev.w3.org/html5/websockets/ [2]: https://fetch.spec.whatwg.org/ -- GitHub Notif of comment by tobie See https://github.com/w3c/sensors/issues/18#issuecomment-103054534
Received on Monday, 18 May 2015 13:15:14 UTC