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

Re: Latest Discovery API

From: Clarke Stevens <C.Stevens@CableLabs.com>
Date: Fri, 8 Mar 2013 17:48:51 +0000
To: Rich Tibbett <richt@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <C29CA37385F0C04593328F0C49935B0917F50498@EXCHANGE.cablelabs.com>
Rich,

After reviewing your responses below, we are satisfied that our our
concerns are addressed as you suggest.

Thanks,
-Clarke

On 2/28/13 2:18 AM, "Rich Tibbett" <richt@opera.com> wrote:

>Hi Clarke,
>
>Clarke Stevens wrote:
>> In the process of writing unit tests for our implementation, we ran
>>across the following issue:
>>
>> Discovery has no way of informing JavaScript that the network has gone
>>down or has never come up. It this case, our Discovery unit tests just
>>hang waiting for a device that will never come up.
>
>I'm not sure this is true (though it's not a function of the NSD spec
>but it is available elsewhere in the web platform).
>
>We have the navigator.onLine attribute that can be used to query network
>connectivity:
>
>console.log( navigator.onLine ? 'Network up' : 'Network down' );
>
>You can also choose to register 'online' and 'offline' event handlers on
>the window object for notifications when the navigator.onLine attribute
>changes:
>
>window.addEventListener('online', function(e) { console.log('Network
>up') }, false);
>
>window.addEventListener('offline', function(e) { console.log('Network
>down') }, false);
>
>I believe this provides the functionality you're after (as a bonus, in
>an agnostic way to the required use of the NSD API).
>
>> We propose adding the following:
>>
>> ---
>> 4.1 Methods
>> Add:
>> 1.a. If there is no network connectivity, invoke errorCallback with a
>>NavigatorNetworkServiceError parameter that has its code set to
>>NETWORK_NOT_CONNECTED.
>>
>> 4.2 Error Handling
>> Add: NETWORK_NOT_CONNECTED value(3)
>>
>> (Note: The NetworkService object has connectivity callbacks, but if we
>>loose connectivity before add device, JavaScript will not get any
>>events.)
>>
>> 5. Obtaining networked services
>> IDL: Add:
>>      readonly attribute boolean  online;
>>      attribute EventHandler     onnetworkonline;
>>      attribute EventHandler     onnetworkoffline;
>> (See 5.3 Events and 6. NetworkService)
>
>We should perhaps reject this based on the availability of
>navigator.onLine.
>
>> ---
>>
>> Also, we expect to pass a string of the body of the event as a
>>parameter on the notify event. This doesn't seem to be defined. Is this
>>the expected usage?
>
>I believe this is specified in the rule to 'setup a UPnP Events
>Subscription' as Step 5.3  (at the bottom of Section 7.2 in
>http://w3c-test.org/dap/discovery-api/#simple-service-discovery-protocol-s
>sdp).
>
>The body of the event is provided as the 'data' attribute on the notify
>event object.
>
>>
>> ---
>>
>> Finally, we want to make sure we're interpreting some terms correctly.
>>Some of this is defined on the top of page 4. This is how I'm parsing it:
>>
>>    *   An existing service is a service that has been discovered, but
>>may or may not have been authorized.
>>    *   An available service is an existing service that matches one of
>>the requested type tokens.
>>    *   A current service is an available service that is currently
>>authorized.
>> Is this correct?
>
>We recently clarified the definition of 'new service', 'existing
>service' and 'current service' in the Terminology section of the spec:
>
>http://w3c-test.org/dap/discovery-api/#terminology
>
>If there are any clarifications we can make to those definitions or we
>require more definitions there please let me know.
>
>Many thanks,
>
>Rich
>
Received on Friday, 8 March 2013 17:50:11 UTC

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