Re: [discovery] Adding CORS to NSD API - proposal and issues

inline comment

regards, Frederick

Frederick Hirsch
Nokia



On Oct 8, 2013, at 5:30 PM, ext Cathy.Chan@nokia.com wrote:

>> From: ext Giuseppe Pascale [mailto:giuseppep@opera.com] 
>> Sent: Monday, October 07, 2013 3:22 AM
>> To: Rich Tibbett
>> Cc: Device APIs Working Group
>> Subject: Re: [discovery] Adding CORS to NSD API - proposal and issues
>> 
>> On Mon, Oct 7, 2013 at 2:45 AM, Rich Tibbett <richt@opera.com> wrote:
>> 
>>>> 
>>>> It has been pointed out before that "device" in UPnP terminology doesn't
>>>> mean one physical device. Actually a "device" in UPnP is somewhat closer
>>> to
>>>> our definition of "service", e.g. a "Media Server" in UPnP is a device,
>>> and
>>>> includes the following services: "ConnectionManager", "ContentDirectory",
>>>> "AVTransport", "ScheduledRecording".
>>> 
>>> [...]
>>> 
>>> My position on this is that a web page can request the four services
>>> above in a single call to getNetworkServices, assuming they intend to
>>> interact with all four services. Otherwise, we the API supports access
>>> minimisation, where a web page could request just "ContentDirectory"
>>> and "ScheduledRecording" to fulfil its use cases.
>>> 
>> 
>> So say device type X is made of services A,B and C:
>> 
>> if I make a search and only get A and B, should I assume that C is not
>> present or not CORS enabled or what?
> 
> Neither. You should assume that the device is crippled and make your web app work with only A and B (e.g. you can stream media to it but would not be able to control the volume), or move on to the next device.
> 
> A similar question needs to be answered if the API allows searches by device type. Since the CORS preflight check is done per service (targeted at the control URL to be specific), what do you do with the device if CORS is supported on some but not all of its services?
> 
>> Also, if all I want is to interact with device types X why should I ask for
>> all services A,B,C and then filter out which one belong to device types X?
>> Since these services are designed to work together, it may only make sense
>> to expose them togheter (or not expose them at all)
>> 
>> 
>>> At the UX level, the user would be authorizing one 'device' and all
>>> requested services belonging to that device would be shared.
>>> 
>>>> 
>>>> I think a web app will be interested in talking to a "Media Server" and
>>> NOT
>>>> to a subset of functionalities of a Media Server services (functions).  I
>>>> think this goes back to the old discussion about UPnP services VS UPnP
>>>> devices: does it make sense to expose single UPnP services rather than
>>> UPnP
>>>> devices? I don't remember if we concluded on that, maybe we should do it
>>>> before we change the spec.
>>> 
>>> I like the concept of grouping device services together but sharing
>>> those sub-components could be done on a need-to-know basis as per the
>>> current spec.
>>> 
>>> 
>> exposing/enabling just a pieace of some devices may not make sense.
> 
> Actually in some cases, it does. There are certain UPnP service types that are not tied to specific device types. Such services can be used independently of all other services on the same device. One example is the LowPowerDevice service type (yes, it's a service that has the word "device" in its name) that allows one to monitor the power state of the parent device. For this reason, I've always been of the opinion that searches by both device type and service type should be supported. 
> 

fjh> reading the thread it seems that this is logical as we cannot anticipate the use cases - some may require finding the device and they using associated services, yet it sounds like in some cases only specific services are needed.

It seems the question is  one of being able to express a query that includes device and/or services - it does not sound like there is a 'natural' constraint. It is orthogonal whether there is an error associated with subsequent steps.


>> Having
>> to fliter-out unwanted services (because I only want services A that are
>> part of device type X) also doesn't make sense. I think we need to change
>> the spec on this.
>> 
>> 
>> 
>>>> 
>>>> Going back to the original issue, my comment above is not that relevant
>>>> anymore if we go for the "alternative" proposal (as I also suggest). It's
>>>> still important to define though what to do with UPnP devices: if only
>>> some
>>>> services support CORS (i.e. the tentative preflight requests on their
>>>> control URL is successful) what should the UA do? Should it be exposed
>>> to a
>>>> web application or not? Should we even allow search for single UPnP
>>>> services, or only for devices?
>>> 
>>> Well these are additional issues we will then need to discuss and
>>> resolve. Right now we minimize access only to the services requested
>>> from a web page and no more.
>>> 
>>> I think some people see changing from service access to
>>> grouped-service (aka 'device') access as a trivial change. It really
>>> is not.
>>> 
> 
> Guilty here, at least for a while. Modifying the object model to support UPnP devices to the same level as services would be a big change - I tried to come up with a proposal and it quickly got out of hand. However, Igarashi-san from Sony made a minimal proposal [1] to enable some form of device representation while leaving much of the complexity to the web page. But I can imagine that adding CORS support to it would require yet more changes.
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0025.html
> - Cathy.
> 
>>> 
>> but may be needed for the way UPnP is designed. I think other people have
>> axpressed this concern/desire. Is there someone else that think the spec
>> should stay as is instead?
>> 
>> /g

Received on Tuesday, 8 October 2013 23:26:21 UTC