Re: [discovery-api] Consolidated comments and questions

Jean-Claude Dufourd wrote:
> Le 8/2/13 16:21 , Rich Tibbett a écrit :
>> 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.
> JCD: I get it at last.
> It is the same thing.
> NetworkServices.onserviceavailable is fired when *a* new service becomes
> available
> NetworkService.onserviceonline is fired when *this* service becomes
> available

Yes! Excellent summary :)

>
> Maybe better names could be NetworkServices.onnewserviceavailable and
> NetworkService.onavailable but I am not positive.

That might be better. I actually considered calling both events 
'serviceavailable'. I wondered whether that would be acceptable or not 
and ended up deciding against it.

Thanks,

Rich

Received on Friday, 8 February 2013 17:09:31 UTC