Re: [discovery-api] Consolidated comments and questions

On Thu, 07 Feb 2013 05:38:58 +0100, Norifumi Kikkawa  
<Norifumi.Kikkawa@jp.sony.com> wrote:
> On Wed, 6 Feb 2013 23:42:59 +0900
> Rich Tibbett <richt@opera.com> wrote:
>> Norifumi Kikkawa wrote:
>> >
>> > 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.
>
> A MediaServer is a deviceType defined to have ContentDirectory
> serviceType (CDS), ConnectionManager serviceType (CMS)
> and optional AVTransport serviceType (AVT). However,
> the combination of CDS, CMS and optional AVT doesn't have to be
> a MediaServer deviceType. These serviceTypes may be used to
> other purpose by definition of UPnP Architecture.
>
> To find a logical entity to serve media library, a user/WebApp
> wants to find a MediaServer, not a combination of CDS and CMS.
> Therefore providing a deviceType seems reasonable and not
> uncessarily abstract to me.
>

I think I agree with Igarashi-san and Kikkawa-san here, it seems to me  
that in the UPnP case, a "device type" is similar to the concept of  
"service" that we want to abstract in NSD, while UPnP services are more  
similar to a subset of "messages" that each service is able to respond to.

Sure, if you allow to search for a UPnP service you can still then  
"construct" your device by searching for multiple services and checking if  
they are from the same device, but why complicating things if the main use  
case is a search for device-type? How many times people need to search for  
specific UPnP services rather than for "predefined collection" of such  
services (i.e. device-types)?

Also, are UPnP services really "independent" if they are part of the same  
"device"? e.g. if I have a Media Server device that includes the 3  
services ContentDirectory(CDS), ConnectionManager (CMS) and AVTransport  
(AVT), can only the CDS be offline while the CMS and the AVT are online?

In general if the 3 services are really just acting as one when they are  
mapped on one "device type" than it makes more sense to threat the UPnP  
device as a "service" in our spec.

Mapping NSD "service" on a UPnP "device" may solve other issues as well,  
e.g. the use of the friendly name for service.name, as well as simplify  
the implementation of the user dialog.


> I doubt that it is useful to provide a phisical device level pop-up
> (if you mean physical device in "we plan to show devices in the opt-in
> dialog to users") because UPnP doesn't provide a physical level metadata.
> UPnP defines lots of things per rootdevice, e.g. friendlyName,
> icon, presentationPage, etc. deviceType is one of them.
> I think UPnP device concept is important for developpers, but this is
> logical concept and does not mean a physical device.
> Per rootdevice pop-up wil be used instead and it's OK IMO.
>
>> 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.
>
> I'm little bit confused here. I don't want a way to find physical
> devices which support more than one specified deviceTypes.
> I'd like to see a way to find UPnP rootdevices which support
> a single specified deviceType.
>
> In your example above, the API realizes deviceType-level search
> which I actually hope though your comments seem negative
> about it?
>
> Regarding version number, UPnP defines a device shall respond
> backward compatible query. For example, a device supporting
> MediaServer:2 will respond to a query to MediaServer:1.
>
> Likewise, I propose the NSD API uses same scheme.
> If WebApp wants to find MediaServer:1 capable device,
>
> navigator.getNetworkServices(
>     'urn:schemas-upnp-org:device:MediaServer:1',
> , function(networkServices) {});
>
> should be sufficient. WebApp shouldn't have to specify
> MediaServer:2,3, or unknown future versions and
> all of them should be returned.
>
> Thanks,
> Kikkawa
>
>> 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
>>
>>
>
> --------------------------------------------------------------
>  Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
>   Sec.1  Dept. No.2
>   Cloud Technology Development Div.
>   COR&D Sony Corporation
>  (TEL) +81 50 3750 3953
> --------------------------------------------------------------
>


-- 
Giuseppe Pascale
Product Manager TV & Connected Devices
Opera Software

Received on Tuesday, 5 March 2013 09:44:20 UTC