AW: [TF-AP] Explicit polling vs leaving it to the server & metadata to optimise

Hi Dave,

as I understand your point that for some cases the promise-based api is too cumbersome.

As this is mainly the idea to have a higher abstraction level for scripts, we could do a call for suggestions.

From your mail I saw:
(examples use a datahandler and errorhandler)

> var datahandler = function (data) { /* do something */ };
> var errorhandler = function (err) { /* handle error */ };

- Getter-function returns a promise
  > thing.requestData(“foo").then(datahandler).catch(errorhandler);
- Fluent-style naming of the getter/setter
 >  thing.foo().then(datahandler).catch(errorhandler);
- Framework abstracts all 
 > datahandler(thing.foo);

I would discourage completely hiding the possibility of exceptions, such as  network faults, but maybe grouping series of operations into a single promise could be an option.
There we can use a proxy object synchronous methods that hide the asynchronous nature of the promise and still can error out.
In js rsp. ES6, you could use setters and getters or you'd have to compare the object after the transaction.
On the far view, this might enable the framework to do transactions and so.
Something like: 

 thing.do((proxy) -> {
  var foo = proxy.foo();
  // or ES6 getter: proxy.foo
  /* do something */  
 }).catch(errorhandler);

"do" is probably the worst name to choose, maybe better "proxy" or "synchronous" or "batch", but the principle should be clear.

What do you think?

BR Johannes


-----
Dave:
> Hi Johannes,
> Further to our conversation during the WoT IG TF-AP breakout, I realised that I had forgotten an important point.
> I believe that you want to support direct polling by applications for thing properties, e.g. for a property named “foo”, you could used something like:
> Whereas, I suggest allowing the server to use the metadata to select the best communication pattern and protocol in order to simplify the job of the app developer, who can then use code like

     /* do something with */  thing.foo

> However, you could still achieve the explicit polling behaviour by defining “foo” as an action instead of a property, e.g. allowing you to write:

      thing.foo().then(function (data) { /* do something */ } );

> since actions are passed up the proxy chain towards the thing.

> Note that the API for creating a proxy is asynchronous, as it could take a while to complete, for instance where the server has to create proxies for things which are properties of the > requested thing. For JavaScript it would make sense to apply promises to this.

> The proxies could be chained to form a tree rooted in a thing. If the proxies use the pull communication pattern, the proxies could cache the property values just as for web resources > accessed via an HTTP proxy chain. The push communication pattern, by contrast propagates changes out from the root to the leaves.

> p.s. my presentation is on the wiki at: https://www.w3.org/WoT/IG/wiki/images/7/7d/Wot-framework.pdf 

> Best regards,
> —
>   Dave Raggett <dsr@w3.org>

Received on Tuesday, 3 November 2015 13:48:41 UTC