Re: [discovery-api] Consolidated comments and questions

Rich Tibbett wrote:
> 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.

On further consideration you can already do this by comparing the host 
and port fragments of both NetworkService.url attributes returned. If 
they are the same then both services belong to the same device.

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

Received on Wednesday, 6 February 2013 14:51:47 UTC