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

Re: Latest Discovery API

From: Rich Tibbett <richt@opera.com>
Date: Thu, 28 Feb 2013 10:18:57 +0100
Message-ID: <512F2101.2090704@opera.com>
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
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 

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 

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
> (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 

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:


If there are any clarifications we can make to those definitions or we 
require more definitions there please let me know.

Many thanks,

Received on Thursday, 28 February 2013 09:19:15 UTC

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