Re: Discovery API proposals: call for comments

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

Received on Wednesday, 12 October 2011 17:23:40 UTC