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

Re: DAP rechartering discussion

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>
Message-ID: <op.vspb3gg66ugkrk@rabdomant-ubuntu>
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:30:14 GMT

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