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


Your proposal sounds interesting.
One thing that I like with it would be to remove the need for web apps to parse the config data fields.
Since it is already done by the NSD implementation, it would be best if done once in usual cases.

Adding a deviceId field for UPnP NetworkService objects makes sense to me.
This field would be a convenient way to group NetworkService objects by devices.
I was expecting this field to be set to the UDN element value.
What is the rationale behind the current choice?

As of UPnP NetworkService name field, would it make sense to directly use the friendly name of the UPnP device?
Currently, it is set to the cryptic serviceId element value which may not be of great use by web apps.
Providing a user friendly name would be more consistent with MDNS NetworkService name fields as well.

I also understood from the proposal that a NetworkService would be added to represent each device itself in addition to the related services.
Is my understanding correct? If so, what is the expected benefit?


From: Igarashi, Tatsuya []
Sent: lundi 7 octobre 2013 13:07
To: FABLET Youenn; Giuseppe Pascale; Rich Tibbett
Cc: Device APIs Working Group
Subject: RE: [discovery] Adding CORS to NSD API - proposal and issues

Hi Tibett and Youenn,

I would like repeat what Giuseppe said, “It has been pointed out before that "device" in UPnP terminology doesn't mean one physical device “.
But it is absolutely tangential. I would suggest to discuss it as the DAP-ISSUE-131.  In addition, I would ask both of you to make your comment on our proposal as below.

Thank you.

Tatsuya Igarashi (<>)
Information Technology Development Div, R&D Platform
Sony Corporation

Received on Thursday, 10 October 2013 12:32:42 UTC