W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2011

Re: DAP rechartering discussion

From: Robin Berjon <robin@berjon.com>
Date: Mon, 21 Mar 2011 14:55:49 +0100
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>
Message-Id: <A5CF7A6C-5CD4-46D0-96C7-E3F0424F0C2B@berjon.com>
To: Giuseppe Pascale <giuseppep@opera.com>
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:58:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:18 GMT