- From: <Cathy.Chan@nokia.com>
- Date: Thu, 10 Oct 2013 18:05:59 +0000
- To: <Youenn.Fablet@crf.canon.fr>, <Tatsuya.Igarashi@jp.sony.com>
- CC: <public-device-apis@w3.org>, <giuseppep@opera.com>, <richt@opera.com>
I'll answer some of these questions as some of them were my idea. Igarashi-san, please feel free to jump in as well. > From: ext FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr] > Sent: Thursday, October 10, 2013 8:32 AM > To: Igarashi, Tatsuya > Cc: Device APIs Working Group; Giuseppe Pascale; Rich Tibbett > Subject: RE: [discovery] Adding CORS to NSD API - proposal and issues > > Hi, > > 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. > This is a compromise done to keep the "device" object as similar to the "service" object as possible, as there were concerns that adding device search introduces way too much complexity to justify it. Specifically, if the "device" object were to contain parsed information about each of the services it contains, as well as embedded devices (and their services, and possibly further embedded devices, and so on), we would be looking at a complete overhaul on the object model. See my analysis at http://www.w3.org/2009/dap/track/issues/131. > 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? > The deviceId was introduced in the spec (not by this proposal) to group all services, embedded devices (and their services) that belong to the same *root* device to facilitate removing everything in one go if a root device is to go offline. Since embedded devices have their own UDNs, using the UDN as the deviceId would cause the embedded devices (and their services) to be "disconnected" from the root device. > 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. > This issue has been raised separately on the main body of the spec. See http://www.w3.org/2009/dap/track/issues/148. It would be better to address it in that context. > 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? > Your understanding is correct. And this is the crux of this proposal. Let's say there is a device X with services A and B. With the current spec, the UA would store an object for A and an object for B, each with their respective service types. A web page would invoke the getNetworkService method with the respective UPnP service type as an argument to find each of these services. (To find both services, it would need to invoke the getNetworkServices method with both service types in the argument.) This proposal adds another object for X, with its device type stored. This enables a web page to invoke the getNetworkService method with a UPnP device type as an argument instead, and the existing algorithm for processing that call would locate the object for X and (upon user permission) pass it on to the web page. Upon parsing the config information, the web page would have information on both services to interact with them. - Cathy. > Regards, > Youenn > >> From: Igarashi, Tatsuya [mailto:Tatsuya.Igarashi@jp.sony.com] >> 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. >> >> http://lists.w3.org/Archives/Public/public-device-apis/2013Sep/0025.html >> >> Thank you. >> >> -***---***---***---***---***---***---***---***---***--***---***---***- >> Tatsuya Igarashi?(Tatsuya.Igarashi@jp.sony.com) >> Information Technology Development Div, R&D Platform >> Sony Corporation
Received on Thursday, 10 October 2013 18:16:26 UTC