Re: [discovery-api] Consolidated comments and questions

Norifumi Kikkawa wrote:
> Hello all,
>
> Thank you for the fine list, Cathy,
> and thank you for the comments to each one, Rich.
>
> Please see my comments below.
>
> On Tue, 5 Feb 2013 23:36:15 +0900
> Rich Tibbett<richt@opera.com>  wrote:
>
>> Cathy.Chan@nokia.com wrote:
>
>>> 4. Allow device type search (and more generally, other UPnP search
>>> strings)?
>>>>  From Naoyuki Sato [11], [13] and Cathy [14]:
>>> It is typically more common for UPnP controller applications to search
>>> for
>>> device types than service types, as controllers tend to expose a
>>> device list
>>> for the user to select from.
>> The abstraction introduced by this specification is at the
>> service-level. At no point would a user agent know what device types to
>> search for since that is not a parameter that can be provided via the
>> getNetworkServices() method.
>>
>> I have updated the specification so implementations can search for
>> 'ssdp:all', 'upnp:rootdevice' or a valid service type token in their
>> UPnP Search. I don't know how we could know to search for a specific
>> device type in this specification. That would be a severe limitation on
>> user choice in selecting services that match those requested by the page
>> and favors the big players to promote and exclude existing and new
>> devices from being discovered via this API.
>>
>> The specification is deliberately device-neutral and service orientated.
>
> I want to use deviceType search with NSD.
>
> Please see Igarashi-san's post [1] explaing "deviceType in UPnP" is a
> service in the sense of generic term such as "MediaServer" or
> "MediaRenderer" feature rather than type of physical device form such
> as "PC" "TV" etc.
>
> For example, A physical device such as a PC can serve both MediaServer
> deviceType and MediaRenderer deviceType features.
> A MediaServer deviceType is defined to provide media library service.,
>
> I agree with you that the NSD has to provide a mechanim for web
> application to find network services regardless which physical device
> holds the services in the network. Therefore, for this purpose,
> I believe the NSD should use UPnP deviceType.
> Note that typically user is not aware of serviceType (a control
> point software does care).

Every device type has one or more service types attached to it. We are 
actually suggesting we skip the step of asking for something 
unnecessarily abstract - a device type with X services - and instead ask 
for specific services of that device via service types.

i.e. If a device type is defined to be the combination of a MediaServer 
and MediaRenderer then if you request those MediaServer and 
MediaRenderer services in a single call to getNetworkServices the user 
can select from a list of the _devices_ that match any or all of the 
service types provided in the opt-in dialog (since we plan to show 
devices in the opt-in dialog to users rather than service types at that 
level). If a device supports e.g. both a MediaServer and MediaRenderer 
then both services will be provided to the web page by the user 
selecting that single device at the prompt.

navigator.getNetworkServices([
   'urn:schemas-upnp-org:device:MediaServer:1',
   'urn:schemas-upnp-org:device:MediaServer:2',
   'urn:schemas-upnp-org:device:MediaServer:3',
   'urn:schemas-upnp-org:device:MediaRenderer:1',
   'urn:schemas-upnp-org:device:MediaRenderer:2',
   'urn:schemas-upnp-org:device:MediaRenderer:3'
], function(networkServices) {});

Selecting a device that supports both MediaServer:2 and MediaRenderer:1 
from the call above will result in the NetworkServices object returned 
in the successCallback containing 2 NetworkService objects attached to 
the same device.

There's room for improvement in binding those services together in the 
resulting NetworkServices object (i.e. indicating that they belong to 
the same device) but I don't think device type search up-front adds 
anything to what we can't already do within the current definition of 
getNetworkServices.

- Rich

>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0010.html

Received on Wednesday, 6 February 2013 14:43:26 UTC