Re: Latest Discovery API

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-ssdp).

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 Thursday, 28 February 2013 09:19:15 UTC