W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

Re: Web API Design Cookbook

From: Dave Raggett <dsr@w3.org>
Date: Mon, 14 Nov 2011 11:36:37 +0000
Message-ID: <4EC0FD45.1020002@w3.org>
To: Robin Berjon <robin@berjon.com>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
On 14/11/11 11:14, Robin Berjon wrote:
> On Nov 10, 2011, at 17:39 , Dave Raggett wrote:
>> On 10/11/11 15:05, Robin Berjon wrote:
>>> Everyone is welcome to contribute (either recipes or empty sections calling out the need for one). The way to do this is through the usual GitHub development process: fork, modify, and make a pull request to the editor.
>> One pattern we could add would be on the role of local synchronous properties that proxy remote properties, e.g.
>>
>>       sensor.temperature
>>
>> where sensor has been previously bound to a local object proxying a remote sensor.  The implementation of the proxy object hides the details of how changes are propagated from the remote service the object proxies.
>>
>> This can be considered as a poor man's version of promises where the proxied property is undefined until it has been set by the object's implementation. This design pattern works nicely where there isn't a need for strict synchronization and you don't want web page scripts to deal with the underlying communication protocol, or to deal with the conceptual challenges of full blown promises including pipelining.
> I'm not sure I'm understanding you correctly. It would seem to me that having a simple attribute access such as "var foo = sensor.temperature;" involve a (necessarily) synchronous access to a remote sensor would be the mother of antipatterns :)
>
> Or is the idea that the calling code would poll the property at regular intervals, getting undefined until it has been set properly? If so, it would seem (to me) that a form of notification would be helpful, no?

It essentially parlays an asynchronous property into a synchronous one. 
This is fine for scenarios where the web developer is happy to leave the 
management of updates to someone else (as is a good idea for battery or 
bandwidth constrained devices).  It subsumes support for notifications 
in that you just need to implement a JavaScript setter for the value, 
i.e. a method that is called when an attempt is made to update the value.

> Either way, the whole point of having this document in GitHub is that it is very easy for people to offer patches ;-) *hint hint, nudge nudge, knowwhatImean?*

I get the hint, and will endeavor to follow through at a later date.

-- 
  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett
Received on Monday, 14 November 2011 11:37:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:24 GMT