- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 14 Nov 2011 12:14:22 +0100
- To: Dave Raggett <dsr@w3.org>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
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? 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?* -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 14 November 2011 11:14:49 UTC