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

Hi Johannes,

I hope you had a safe return journey from Japan. I am now in train to Brussels, but thankfully, don’t have much travel for the rest of the month. My responses are inlined below.

> On 3 Nov 2015, at 13:48, Hund, Johannes <johannes.hund@siemens.com> wrote:
> 
> 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.

Faults need to be dealt with at the matching layer of the architecture as otherwise we are breaking the separation of concerns and introducing a code dependency across layers. This means that we need a fault model for each layer.

> 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.

I’ve successfully used setters and getters in my NodeJS based web of things server. These are automatically set up by the server for both things and proxies for things based upon the thing’s description. As you suggest, faults could result in JavaScript exceptions, subject to the layering concerns mentioned above.

> 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.

For some application scenarios where safety and compliance to business rules are essential, we may indeed need to introduce transactions and roll-backs.  This should be the subject of a future study.

> 
> 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>
> 
> 
> 

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>