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 your response. By other contexts, I basically mean all the cases where a web app would like to interact with a remote device/service but without having to rely on WoT model.

This may especially be the case when interacting with local devices that can run servers, such as network cameras, TVs, copiers... Services running on such devices can be discovered based on their types (e.g. UPnP service types), said types also defining how to interact with selected services. Therefore, in this context, relying on WoT model and WoT-customized API is not necessary. More generally, not all services may want to provide a Thing Description, just like not all web services provide a WSDL description. A generic API would allow addressing such cases.

Of course, it would be possible to define a generic API on top of Thing API (e.g. by defining default "sendMessage" action and "onmessage" event), but it seems more logical to define a specialized API over a generic API than the other way around.

Regards,

Romain.

> -----Original Message-----
> From: Bassbouss, Louay [mailto:louay.bassbouss@fokus.fraunhofer.de]
> Sent: vendredi 9 octobre 2015 18:22
> To: BELLESSORT Romain; 'fd@w3.org'; 'Hund, Johannes'; public-wot-
> ig@w3.org
> Cc: FABLET Youenn
> Subject: RE: [TF-DI] Thing API proposal (was RE: [TF-DI] Agenda and webex
> details - 24 Sept 2015 at 15:00 CEST)
> 
> Hi Romain,
> 
> Thx for your feedback, I saw your Mail on the Presentation API CG ML. As
> you said, the Thing API proposal follows some Ideas of the Presentation API
> especially for abstracting from Discovery and Communication technologies as
> well as showing Selection Dialog for the user (Select Displays vs Select
> Things). I agree with you that we can make a more generic API for
> communication that can be customized to support WoT TD and other
> contexts. Do you have use cases that covers "other contexts"?
> 
> regards
> Louay
> ________________________________________
> From: BELLESSORT Romain [Romain.Bellessort@crf.canon.fr]
> Sent: Friday, October 09, 2015 1:12 PM
> To: Bassbouss, Louay; 'fd@w3.org'; 'Hund, Johannes'; public-wot-ig@w3.org
> Cc: FABLET Youenn
> Subject: 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 Monday, 12 October 2015 17:06:04 UTC