- From: Norifumi Kikkawa <Norifumi.Kikkawa@jp.sony.com>
- Date: Thu, 07 Feb 2013 13:38:58 +0900
- To: Rich Tibbett <richt@opera.com>
- Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Rich, thank you for your reply. Please see my comments below. On Wed, 6 Feb 2013 23:42:59 +0900 Rich Tibbett <richt@opera.com> 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. 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 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 --------------------------------------------------------------
Received on Thursday, 7 February 2013 04:39:30 UTC