Re: Discovery API proposals: call for comments

I see what you're saying, but I think current browsers specifically
prohibit some of the things we need (evented discovery, cross origin
communication, etc.) and therefore JS can't solve the problem. I actually
think we're looking at the same goal, but limiting the solution of the "no
change in browsers required" goal to "JavaScript" may not be possible.

-Clarke

On 10/12/11 1:29 PM, "Bryan Sullivan" <blsaws@gmail.com> 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.
>
>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-Polyfill
>>>s
>>>
>>>
>>
>>
>
>
>
>-- 
>
>Thanks,
>Bryan Sullivan

Received on Wednesday, 12 October 2011 20:00:13 UTC