Re: Discovery API proposals: call for comments

On Wed, 12 Oct 2011 21:29:17 +0200, 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.
>

An API that can only be implemented 100% in JS is not what we are after  
(or at least what Opera and CableLabs are proposing).
We are still aiming for minimal impact on the user agent, but if you want  
to support ALL use cases you need some support from the browser.

To be clear: I'm not saying that what you suggest is wrong in general, is  
just not completely applicable for this specific case
(at least if you want to achieve reasonable performances).

Of course some of these functionalities can be implemented via a plugin  
(Netscape Plugin), that is always a possible fall-back.

Furthermore I don't think writing the high level API is something we want  
to do in this first round.
Our suggested plan would be:
- we start providing means to do discovery from an application (this work)
- we go back to our PCs and experiment with these new mechanisms in  
Javascript
- (maybe) we look into standardizing an higher level API


/g


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


-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software

Received on Thursday, 13 October 2011 08:10:28 UTC