Re: Discovery API proposals: call for comments

Bryan Sullivan wrote:
> The point of the goal of a pure JavaScript implementability is not to
> avoid the need to define an API as JavaScript interfaces etc, but to
> ensure that the resulting API can be implemented by a JavaScript
> library for use in devices that do not have the User Agent direct
> implementation. For example, json2.js was widely used for JSON
> functions, but is now becoming not important as browsers are
> implementing EcmaScript 5 with the native JSON support. So json2.js
> first tests to see if the JSON interface is defined, and if so does
> nothing, letting the native implementation handle it.
>
> In the same way, W3C can define a real API using WebIDL which has all
> the typical interfaces, attributes, etc, but it should be possible to
> emulate the native support for the API through JavaScript. This will
> both speed adoption and broaden the set of supporting devices.
>
> How such an API might be bound to service access points (e.g. a media
> source), e.g. if over HTTP or some new URI scheme (with a handler in
> the device), etc, can the next step in implementation choices beyond
> browser-native API support.

FWIW, while writing our proposal we experimented heavily with what's 
possible to emulate in JavaScript today. We could emulate all service 
communication minus the ability to automatically resolve service 
configuration information and communication endpoints from the network.

So our proposal is a very small API to expose that to web pages and let 
them manage the rest as they do today. If you want to capture service 
configuration and communication information from messages at the DNS-SD 
and UPnP level then a library could emulate that via some Flash module.

So yes, I believe we could create polyfills to back-port this to other 
browsers...subject to someone actually going ahead and showing it can be 
done.

- Rich

Received on Thursday, 13 October 2011 08:31:37 UTC