RE: about high-level or low-level API (ISSUE-17)

Agree with Mark on the Crawl-Walk-Run approach as this will help us enable basic mechanisms first and iron out all potential implementation issues.

- narm

narm gadiraju
narm@intel.com<mailto:narm@intel.com> | W: 503-712-8599 | M: 503-705-0573


From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3..org] On Behalf Of Vickers, Mark
Sent: Wednesday, June 15, 2011 5:15 PM
To: Clarke Stevens
Cc: Russell Berkoff; Bob Lund; Jean-Claude Dufourd; public-web-and-tv@w3.org
Subject: Re: about high-level or low-level API (ISSUE-17)

I think this is a crawl-walk-run situation.

Currently, browsers are at the standing still phase of home networking because they can't even discover or connect to a home network device or service..

An initial crawl phase:
- discovery and generic messaging
- requires key security and privacy issues be addressed. I think user-permission will be required.
- should work for any protocol family: UPnP, ZeroConf, SLP, etc.
- higher-level, ecosystem support (UpNp/DLNA, BonJour) could be built in JS applications or in JS libraries

Following walk-run phases:
- Probably several service-specific requirement/API efforts, different difficulty, different expert groups
- May need to address service APIs that work on both LAN & WAN

Just developing secure, privacy-protecting, generic discovery and messaging requirements and APIs for the crawl phase will be a major accomplishment.

Thanks,
mav

On Jun 15, 2011, at 3:54 PM, Clarke Stevens wrote:


Russell,

Let me address your points below. I've done some prototyping on this, so I have a pretty good idea of at least one way to do it.

-Clarke

From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Russell Berkoff
Sent: Wednesday, June 15, 2011 4:33 PM
To: Bob Lund; Jean-Claude Dufourd; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: RE: about high-level or low-level API (ISSUE-17)

Hello,

I'm guess I'm confused on a number of accounts:

1.  How does a "generic" discovery framework address the needs of existing ecosystems with existing and well established discovery and network protocols.
>>The "browser" (integrated, plug-in, applet, etc.) can send and receive messages that are reduced to strings. The logic of how these messages are handled can be done at the JavaScript layer. In our experiments we can do this with APIs that work for both UPnP and ZeroConf (Bonjour).
2.  How does a UA support one (or more) of the existing HomeNetwork standards? I thought (an) objective of HTML5 was to eliminate the need for browser-specific plug-in modules?
>>It's impossible to implement a specific protocol without defining that protocol on some level. One way to do this is to have a generic class that implements a generic interface and derive protocol specific subclasses from that to do the actual implementations.
3.  How does a UA (in particular one that provides Device/File services) connect to platform devices and files? I suspect that the demands for metadata storage alone would greatly exceed what is anticipated in WebStorage.
>>You don't need to read everything at once. You can limit (e.g. through a hierarchical interface or limiting the number of displayed items) the user interface to something that is manageable in the available memory space.
4.  How would generic UA network access services to do discovery and commanding be secure? In theory any webpage/plugin code could "hijack" a UA causing security and privacy issues.
>>Security is relative. Having said that, an authenticated application from a trusted source using the security features of the specific protocol or link-level security are tools we can use to increase the relative security level.

I think it would be helpful if the IG focused more on deriving real-world requirements. If anything the discussion seems to indicate that the high-level requirements in ISSUE-17 may result in additional requirements on the UA platform to provide the necessary support for HNTF access methods for currently deployed HNTF network technologies. I would suggest the IG address these items.

>>I strongly agree that we need to work with existing protocols and the accomplishment of this objective is a key measure of the success of HNTF. Fortunately, the low-level solution does not preclude the high-level solution. Specification of the high-level solution brings additional challenges in abstracting protocols with different approaches and assumptions. I think this is something that we need to consider, but I think the group can provide the simpler and more general solution in the meantime.

Regards,
Russell Berkoff
Samsung


-----Original Message-----
From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Bob Lund
Sent: Tuesday, June 14, 2011 9:54 AM
To: Jean-Claude Dufourd; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: RE: about high-level or low-level API (ISSUE-17)



> -----Original Message-----
> From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org> [mailto:public-web-and-tv-
> request@w3.org] On Behalf Of Jean-Claude Dufourd
> Sent: Tuesday, June 14, 2011 10:10 AM
> To: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
> Subject: about high-level or low-level API (ISSUE-17)
>
> Dear all,
>
> I want to ask my question again in writing, because I did not get an
> answer during the call and yet I think we need to answer it in order
> to know what to do with ISSUE-17.
> What is the intent of ISSUE-17 ?
> Is it to standardize a list of API calls, the first of which (in the
> text) being "list discoverable home network media servers" ?
> Or is it to standardize a generic messaging API, and check that
> everything listed in ISSUE-17 is possible ?
> This actually applies to more than just ISSUE-17
>
> If it is the first, then it is meaningful to discuss ISSUE-17 in
> detail, bullet by bullet. So we would need a lot of telco time.
> If it is the second, then I believe it is not meaningful to discuss
> ISSUE-17 bullet by bullet, but just keep the list for later validation
> of the standard. If so we should not have spent as much time on it in
> today's telco.
>
> Then my opinion on this subject is that we should only standardize a
> small, low-level API for generic messaging, and not a very large set
> of high-level messages that would never be up-to-date in the rapidly
> evolving ecosystem of the home network.
> We should definitely design a standard that allows a document to call
> any of the UPnP/DLNA services mentioned in ISSUE-17, but does not
> duplicate the UPnP/DLNA service interfaces.

I agree with this. In addition to the issue of staying up to date, some home networking technologies do not standardize the semantics of a particular service interface, DNS-SD for example. There is a general discovery mechanism and a generic syntax for exchanging messages but the contents of the message are specific to the service. Exposing a service specific API in the user agent then implies the user agent has service specific knowledge. Clearly this does not scale.

I think the best course of action is to start with a generic API that focuses on service discovery and a generic message passing and event mechanism. As the industry gets experience with this, it may become that higher level APIs would be appropriate. JavaScript functions could be defined to provide a home network technology specific interface if that is felt to be valuable.

Bob
> Best regards
> JC
>
> --
> JC Dufourd
> Directeur d'Etudes/Professor
> Groupe Multimedia/Multimedia Group
> Traitement du Signal et Images/Signal and Image Processing Telecom
> ParisTech, 37-39 rue Dareau, 75014 Paris, France
> Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
>