- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 21 Mar 2011 14:55:49 +0100
- To: Giuseppe Pascale <giuseppep@opera.com>
- Cc: "Matt Hammond" <matt.hammond@rd.bbc.co.uk>, "Mark Watson" <watsonm@netflix.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>, "Olivier Thereaux" <olivier.thereaux@bbc.co.uk>
Hi Giuseppe, On Mar 14, 2011, at 12:11 , Giuseppe Pascale wrote: > How do you think it would fit into a more generic work around "home networking API", that is devices discovery and control inside the home network (UPnP-like)? Just a small note: one thing that I would hope we do is that we would not create one big, monstrous "home networking API". Big monolithic projects are hard to specify, and when they eventually get specified they take ages to implement — assuming there still are any implementers around by that time :) That's why, in the context of potentially working on this in the DAP group, I think it is best to try and split the UC API into smaller bits, and see what needs to be supported on the client and on server implementation. What I see in the client is mostly: - an API for discovery of some sort; - perhaps an API for security pairing (something like GSSAPI maybe?). I don't see browsers implementing the client side of the UC API, or rather I don't see that as being necessary. Would it for instance make sense to specify the above two here, and the protocol in a TV group? This is just a thought — I'm simply wondering if the responsibility split makes sense that way. -- Robin Berjon - http://berjon.com/
Received on Monday, 21 March 2011 13:56:22 UTC