RE: DAP rechartering discussion

+1 to simplicity and leaving protocol and formats to TV group.

Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Monday, March 21, 2011 8:56 AM
To: Giuseppe Pascale
Cc: Matt Hammond; Mark Watson; public-device-apis@w3.org;
public-web-and-tv@w3.org; Olivier Thereaux
Subject: Re: DAP rechartering discussion

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/





---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Monday, 21 March 2011 16:31:53 UTC