- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Mon, 21 Mar 2011 17:29:30 +0100
- To: "Robin Berjon" <robin@berjon.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 Robin, On Mon, 21 Mar 2011 14:55:49 +0100, Robin Berjon <robin@berjon.com> wrote: > 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 :) > No need to worry, since what we are discussing here are usecases and requirements, not specifications; as is stated also in the requirement document draft "A number of specifications may be created to address the requirements enumerated in this document.". For what is worth, I personally agree whit your statement above (better modularized specs than huge monolitic ones) even though I'm not sure that the right level of modularisation is any easy task to achieve. Extremely huge and extremely small is of course easy to discard, but between these 2 extremes the are infinite possibilities and what is the best approach is not always easy to decide. Anyway, this is another discussion :) > 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. > The aim of this TF is exactly to identify the needed (missing) pieces. Without that, is difficult to decide who should do what. If you try to do the split before the requirement are complete, you risk potential overlaps and conflicts. Also note that there is already some potential overlap with the RTC WG scope [1]. Anyway, since the usecases here discussed are really cross-devices, would make sense to work together to identify requirements and then discuss how the work should be split. So I would like to invite any interested party in the DAP group to join the TF activities and help draft the requirement document. More info (still WiP) are available on the IG wiki [2] [3] Note: I'm not sure if that's the best way to reach all DAP participants; would you mind (as chair of the WG) to forward this invitation to guarantee that all potentially interested parties are notified? [1] http://www.w3.org/2010/12/webrtc-charter.html [2] http://www.w3.org/2011/webtv/wiki/Main_Page [3] http://www.w3.org/2011/webtv/wiki/Home_Network_TF_Requirements -- Giuseppe Pascale TV & Connected Devices Opera Software - Sweden
Received on Monday, 21 March 2011 16:32:16 UTC