W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2011

Re: Discovery API proposals: call for comments

From: Bryan Sullivan <blsaws@gmail.com>
Date: Mon, 10 Oct 2011 21:41:09 -0700
Message-ID: <CAA2gsfq3hTT9O58hQZ2zG3=EoGFW40LsfguTp6+Bm1_G7krgEA@mail.gmail.com>
To: Giuseppe Pascale <giuseppep@opera.com>
Cc: public-device-apis@w3.org, Dave Raggett <dsr@w3.org>
Being able to prototype and implement such an API entirely in
JavaScript for an HTTP-based binding would be very valuable, for the
reasons Giuseppe mentioned (extensibility) and also as Dave mentioned
and Claes illustrated in his demo
(http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0008.html)
avoiding any impact to the browser whatsoever, given that there was a
HTTP-based service exposing the API in the local network (or even on
the same device, as a local server resource). This would enable such
services to be added-on to existing devices through downloadable
software (without impacting the browser), and also make them available
to completely uncustomized devices.

We should take care to ensure that the API is implementable in
JavaScript purely.

Thanks,
Bryan Sullivan

On Thu, Oct 6, 2011 at 6:59 AM, Giuseppe Pascale <giuseppep@opera.com> wrote:
> On Mon, 26 Sep 2011 16:59:48 +0200, Dave Raggett <dsr@w3.org> wrote:
>
>> On 26/09/11 07:57, N.V.Balaji wrote:
>>>
>>> Instead of providing a URL to access the service as with the
>>> getNetworkedServices proposal, the service object directly exposes the
>>> interface for accessing the service.
>>>
>>> [NVB]: That would mean that the interface JavaScript API should be
>>> defined for each service type.  Pl. correct me if I am wrong.  Given the
>>> enormity of this task (of defining APIs that can work over multiple
>>> protocols and
>>> implementing them) it is better that we go for a simpler approach, even
>>> if it is narrower in scope.
>>
>> This is an incremental process. We start with existing services and add
>> new ones as they are deployed.A simple solution for new services is to use a
>> generic interface that passes data as JSON. As one step beyond that, I am
>> looking at a means to automatically generate live interfaces from JSON
>> declarations, where the interface maps into a JSON RPC call. This is all
>> transparent to the web page script developer. In the longer term,  I would
>> like to see an ecosystem where third parties provide extensions for an
>> increasingly wide range of devices and services. This is particularly
>> valuable for services where you need a service specific driver, e.g. for
>> many USB devices.
>
> If you have an API like the one we have proposed, could you do this in
> javascript, so to be transparent to the browser?
> It will be much easier for you to prototype in Javascript than having to
> modify the browser source or having to convince a browser manufacturer to
> support your service.
>
> /g
>
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software
>
>



-- 
Thanks,
Bryan Sullivan
Received on Tuesday, 11 October 2011 04:41:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:23 GMT