RE: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex details - 24 Sept 2015 at 15:00 CEST)

Hi Louay,

Thanks for this interesting proposal. We have been following both Presentation API and WoT IG, and we agree that Presentation API may provide a good model for a broader discovery and interaction API (we have recently proposed that Second Screen CG may work on such an API [1], but of course we would also be interested if things were to happen in another group).

In addition to comments regarding the number of devices (selection, filtering), which have already been addressed, I was wondering about the scope of this API. Your proposal is somehow specific to WoT model as it relies on property/action/event. This perfectly makes sense in WoT context, but have you investigated the opportunity for simply defining how to send/receive messages, as in Presentation API? Such an API could then be customized to obtain something like the Thing API in WoT context, or another API in another context. Maybe your implementation builds over such a generic message exchange primitive?

Regards,

Romain.

[1] https://lists.w3.org/Archives/Public/public-webscreens/2015Oct/0000.html


> -----Original Message-----
> From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
> Sent: vendredi 25 septembre 2015 12:59
> To: 'fd@w3.org'; 'Hund, Johannes'; public-wot-ig@w3.org
> Subject: AW: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex
> details - 24 Sept 2015 at 15:00 CEST)
> 
> Hi Francois,
> 
> Thx a lot for your feedback ;) please find my comments inline.
> 
> Louay
> 
> >
> > Not raised during the call as I was busy scribing, but I have a couple
> > of comments as well, so thought I'd share them here.
> >
> > The Presentation API is currently limited to selecting only one second
> > screen at a time. That is not a real problem as the main use cases
> > considered only involve one second screen (at least one second screen
> > at a time). However, I wonder whether discovery of a single Thing is
> > also a common use case for connected objects.
> >
> > For instance, looking at the Generic Sensor API [1] that was mentioned
> > during the call, I see that the entry-point to that API is to retrieve
> > and monitor *a list of sensors*. Although a Thing in the WoT case may
> > be contain more than one sensor, I suppose that, most of the time, the
> > mapping will be one Thing per physical object, as in "a light bulb". I
> > see value in the ability to select and interact with a particular
> > light bulb, but I also think that it might be useful to select "all the light bulbs
> in this room" for instance.
> >
> > Would supporting the ability to select more than one Thing at a time
> > be useful? Do you see what API changes could do the trick? (That
> > feature could actually be useful for a future version of the
> > Presentation API)
> [Louay] Completely agree on this I think I see more relevance in the Thing
> API for multiple select than for the Presentation API because in the
> Presentation API when you start a PresentationRequest the presentation
> page  will be launched  when the user  selects a display but in the Thing API
> proposal the web page will only  get the thing.
> To support multiple changes an array of things can be passed to the page
> when the Promise is resolved instead of only one (input things instead of
> thing):
> ThingRequest(filter).start().then(function(things){…}).catch(function(err){…}
> );
> >
> > Also, although we're addicted to screens, the typical number of
> > available displays for the Presentation API should remain pretty small
> > in most contexts. There may be more Things to choose from, which might
> > mean that the list could grow out of control. I suppose that the user
> > agent could be smart enough to group things together but that would
> > require additional logic on their side.
> [Louay] Yes this is a feature of the UA how to show the Things in the Dialog.
> E.g.
> the UA may offer groups and search field and also sort things according to
> user preferences or proximity.
> >
> > Or it may be that the light example is not a very good one. Requiring
> > the user to select a light in a list just to be able to switch it on
> > or off may not lead to the best user experience. The API may be much
> > more useful to interact with more complex things: the user won't have
> > many of them and selecting only one will be the default need. What do you
> think?
> [Louay] yes I agree if the user always needs to  select a Thing from the Dialog
> to interact with it is not a good user experience. This is why in my API
> proposal there is another function
> navigator.things.getById(id).then(...) which is relevant for things that are
> already selected by the user.
> This means the user needs to select a Thing from the dialog only once in most
> case. The dialog is needed to get access to NEW  things which are not
> available yet for the web page. The web page can use in addition the
> function
> thing.getReachability().then(function(reachability) {
>  handleReachabilityChange(reachability.value);
>  reachability.onchange = function() {
> handleReachabilityChange(this.value);}
> });
> to watch the reachability of a Thing. This is very similar to the getAvailability()
> function in the Presentation API.
> >
> > Thanks,
> > Francois.
> >
> > [1] https://w3c.github.io/sensors/

> >

Received on Friday, 9 October 2015 11:13:18 UTC