RE: [discovery-api] Consolidated comments and questions

> -----Original Message-----
> From: ext Giuseppe Pascale [mailto:giuseppep@opera.com]
> Sent: Tuesday, March 05, 2013 4:44 AM
> To: Rich Tibbett; Norifumi Kikkawa
> Cc: public-device-apis@w3.org
> Subject: 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.
>
Very well put.

> 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 like that a lot!

- Cathy.

>
> > 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.h
> >> tml
> >>
> >>
> >
> > --------------------------------------------------------------
> >  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