W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2013

Re: [discovery-api] Consolidated comments and questions

From: Rich Tibbett <richt@opera.com>
Date: Fri, 08 Feb 2013 16:21:21 +0100
Message-ID: <511517F1.8020700@opera.com>
To: public-device-apis@w3.org
Jean-Claude Dufourd wrote:
> Le 8/2/13 15:27 , Rich Tibbett a écrit :
>>
>>>
>>> And also, my question about polling boils down to: what is the practical
>>> difference between "available" and "online" ?
>>
>> 'available' means that the service is present on the local network but
>> not yet shared with any web page.
>>
>> 'online' means the the service is present on the local network and
>> shared with a web page.
>>
>> We settled on these terms for lack of a better naming suggestion.
>>
>>>
>>> What is "online" ? A response to ping is characteristic of the device,
>>> not of the service.
>>> Is there anything standard in Bonjour and UPnP that can be used as a
>>> test of online-ness ?
>>
>> 'online' is a concept specific to this specification when a
>> NetworkService object is provided to a web page. At that point the
>> service is either online or offline for that web page to interact with.
>>
>>> Should the implementation poll for that ?
>>> Should the online attribute and events not be optional (SHOULD or MAY,
>>> rather that MUST now) ?
>>
>> There is some use to receiving these events for a web page. There is
>> the option for the web page to check the online-ness of a shared
>> NetworkService object by querying its .url attribute via an e.g. XHR
>> call. If that fails with a 4XX then they may be able to assume that
>> the service is no longer responding and hence offline.
>>
>> Since we're aware of general registration/deregitration/expiry of
>> Local-networked Services in the network at the underlying
>> implementation level we provide any status updates we can through the
>> 'online' attribute of the corresponding NetworkService object as a
>> convenience feature.
>>
>>> If it is too similar to "available", should it not be removed
>>> altogether ?
>>
>> It seems there's enough of a difference to warrant both events. One is
>> a generic notifier of the state of the network relating the requested
>> service types fired against NetworkServices. The other is a specific
>> notifier of the state of the service fired against its corresponding
>> NetworkService object.
>>
> JCD: I still do not understand the difference.
> You write:
> /'available' means that the service is present on the local network but
> not yet shared with any web page. //
> ////
> //'online' means the the service is present on the local network and
> shared with a web page. //
>
> /If "I" see a NetworkService object, then it has been provided to the
> web page "I" am in.

Yes.

> A NetworkService object has no existence (for the purpose of this
> standard) until it is provided to a web page.
> So if "I" see it, then online and available must have the same value.
> Best regards

Yes, in this particular case that will be true.

If we take another scenario, where I don't have access to a 
NetworkService object but where a new service is detected on the 
network, then the user agent is still going to fire a serviceavailable 
event on the NetworkServices object (since I don't have any binding of 
that service to a NetworkService object there can be no serviceonline 
event fired). This is still useful because it is an indicator that I can 
re-invoke getNetworkServices if I wish and more devices will be 
available in the list presented to the user.

When you're working with a NetworkService object it's quite important to 
know whether _that particular service_ is available or not. In that 
sense, 'online' is for tracking a shared service's availability and 
'servicesAvailable' is for tracking the general number of services 
available on the current network(s).

Like I said previously, we can change the naming here if there are any 
better suggestions but I feel the need for both events is still justified.

- Rich
Received on Friday, 8 February 2013 15:21:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC