Re: DAP rechartering discussion

I also agree - subdividing would simplify re-use of common components -  
such as the discovery and security aspects.

 From the BBC's perspective: our original goals (enabling the creation of  
remote control devices that will work with many manufacturer's TVs/STBs)  
can still be met by profiling the use of a combination of these components.



Matt

On Mon, 21 Mar 2011 13:55:49 -0000, Robin Berjon <robin@berjon.com> wrote:

> 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.
>


-- 
| Matt Hammond
| Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/