Re: Discovery API proposals: call for comments

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.

Thanks,
Bryan Sullivan

On Wed, Oct 12, 2011 at 10:22 AM, Clarke Stevens
<C.Stevens@cablelabs.com> wrote:
> I find this a little confusing and arbitrary. In my mind, the "API" is
> what we are asking W3C to add to HTML to enable the discovery features we
> want. "Pure JavaScript" seems to imply that we don't need an API, and are
> therefore asking for nothing.
>
> I think the goal of a minimal API that only requests the changes required
> to enable the features we are seeking is desirable. CableLabs has an
> implementation of the discovery API that uses a JavaApplet to provide the
> minimal necessary functionality to provide UPnP/DLNA and Zeroconf/Bonjour
> features to currently shipping browsers. The API is very basic. Much of
> the UPnP or Zeroconf interface needs to be built in JavaScript. We expect
> that the applet will eventually be superceded by embedded browser
> implementations (if the API is successful). This will mean the features we
> want will eventually be implementable in "pure JavaScript," but the "API"
> is specifically NOT JavaScript - and that is why we are asking for it.
>
> This may just be a difference in the interpretation of the meaning of API.
> We may all be thinking the same thing, but I wanted to clarify how I am
> viewing it.
>
> Thanks,
> -Clarke
>
> On 10/12/11 9:55 AM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com> wrote:
>
>>Hi,
>>
>>On 12.10.2011, at 18.19, ext Giuseppe Pascale wrote:
>>
>>> On Wed, 12 Oct 2011 17:05:29 +0200, Anssi Kostiainen
>>><anssi.kostiainen@nokia.com> wrote:
>>>
>>>> As per the discussion during today's call, I added the following step
>>>>to the API checklist: "the API should be implementable in pure
>>>>JavaScript to allow shims for browsers that do not have native
>>>>implementations":
>>>>
>>>>  http://www.w3.org/2009/dap/wiki/ApiCheckList
>>>>
>>>> Sometimes obeying this rule may not lead to the best possible design,
>>>>thus "should". Feel free to embellish.
>>>>
>>> Of course not everything will be implementable in javascript. If that
>>>was the case already, then why bothering writing a spec, we should be
>>>writing a js library.
>>> The concept I (we) are trying to push is that, when possible, a design
>>>that allow an high level API to be designed on a small set of features
>>>embedded into the browser is desirable.
>>
>>I think we're after the same thing. I mean the API should allow shims, or
>>to be exact polyfills [1], such as [2].
>>
>>I reworded the statement a bit to make this clearer:
>>
>>"the API should be implementable in pure JavaScript to allow shims that
>>mimic the API and provide fallback functionality"
>>
>>-Anssi
>>
>>[1] A shim that mimics an API providing fallback functionality to older
>>browsers.
>>[2]
>>https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills
>>
>>
>
>



-- 

Thanks,
Bryan Sullivan

Received on Wednesday, 12 October 2011 19:29:46 UTC