W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: [widgets] Device Specific APIs and Services

From: Marcos Caceres <marcosscaceres@gmail.com>
Date: Sat, 21 Jun 2008 10:40:43 +1000
Message-ID: <b21a10670806201740r22928a7ej988ada07782a7015@mail.gmail.com>
To: timeless@gmail.com
Cc: "public-webapps@w3.org" <public-webapps@w3.org>

On Fri, Jun 20, 2008 at 8:32 PM, timeless <timeless@gmail.com> wrote:
> On Fri, Jun 20, 2008 at 11:37 AM, Marcos Caceres
> <marcosscaceres@gmail.com> wrote:
>> APIs are identified as resources via URIs. For
>> example:
>>
>> <widget>
>>        <access network="true">
>>                <requires id="gps"
>>                                     src="http://gps.w3.org/api.jar"
>
> This worries me. see clsid: and the problems of activex for porting platforms.
>
> (I work on microb, and we're trying to have support for the series 60
> browser widgets which have a number of things which I really don't
> like and which we can't easily implement.)

Can you describe those things you don't like and why? That way, we can
avoid similar features in our spec if need be.

>
>>                                     type="application/jar"
>>                                kind="api" />
>>        </access>
>> </widget>
>
>> The interfaces that bind this binary component to JavaScript would
>
> bad. Is api.jar really the binary component?

I guess it doesn't have to be... but the component must provide
functionality beyond what is provided by default by the widget engine.
This feature would not be used to load in JS, as the <script> element
is for that.

> If what you mean is that api.jar contains an IDL file or something
> equivalent to this, then it may be OK, although the language
> definitely needs work.

That is what needs to be standardized. For example, a Widgets 1.0
widgets engine does not ship with a GPS API; how is such an API bound
dynamically at runtime in a standards compliant way?

>> need to be standardized and I have no idea what they would look like
>> at this point.
>
>> interface APILoader{
>>  attribute APILoader APILoader(DOMString id); // the id declared
>
> sorry, i don't recognize this syntax. typically attributes don't take arguments.

oops, ignore the attribute bit.

>>  void load();         //load the API
>>  void cancel();     //cancel loading
>
> what happens if the load has already finished?
>
> can i unload() ?

Sure, why not.

>>        gps = loadedAPI.bind();
>
> you declared load() earlier, not bind().
>

I thought you could load() it, and then bind() it when you need it.
Eg, I have a flickr widget to tag photos on my device, but it also
allows me to take pictures, via a camera API, if my device has a
camera. If I am just doing tagging and uploading I don't need to
bind() the camera API. Once you want to take a photo, you bind() the
camera API.

-- 
Marcos Caceres
http://datadriven.com.au
http://standardssuck.org
Received on Saturday, 21 June 2008 00:41:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT