W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: [widgets] Interface published

From: Robin Berjon <robin@berjon.com>
Date: Mon, 30 Nov 2009 14:42:52 +0100
Cc: Kai Hendry <hendry@aplix.co.jp>, public-webapps <public-webapps@w3.org>
Message-Id: <6F613F79-2CB4-443D-B5D8-FA75DA8D5A2D@berjon.com>
To: Marcos Caceres <marcosc@opera.com>
On Nov 25, 2009, at 15:52 , Marcos Caceres wrote:
>> If the <http://www.w3.org/TR/widgets-apis/#the-preferences-attribute> was
>> mandatory, which I think it should be since many widgets I've come across rely
>> on **setPreferenceForKey** and **preferenceForKey** conventions, wouldn't it be
>> sensible to put the interfaces all into this **preference** [Web
>> storage](http://www.w3.org/TR/webstorage/) mechanism?
>> Consider read-only keys like:
>>        widget.getItem("name")
>>        widget.getItem("nameShort")
>>        widget.getItem("authorEmail")
>>        widget.getItem("licencseHref")
> However, a generic "getItem" might have been nice (and extensible)

Wow yeah, why did we never think of that? In fact, we could replace all of our APIs with this one:

interface DoEverything {
    any getItem(in DOMString itemName);
    void setItem(in DOMString itemName, in any itemValue);
    any doStuff(in Function stuffToBeDone);

That way everything would be nice and extensible! Just look:

Instead of:


you have:


and instead of:


you have:


Revolutionary? Well, if you're in business selling keyboards and RSI relief, maybe.

>> Though perhaps ideally when you did a `widget.getItem`, you received the JSON
>> representation of the XML fragment. Though I'm not entirely sure if there is a
>> standard way to map XML onto JSON. You might as well canonicalise the whole
>> `config.xml` as a JSON string bound to **widget.config**. There, simple.  Or
>> `innerXML` if a JSON translation isn't possible.

There isn't a standard mapping from XML to JSON, but there have been experiments mapping the Infoset to JSON. Good luck using that here!

All of these things seem like more work. Right now all that is done is that we map to what's in the configuration table after P+C has run. That's information that the UA must already have, and can trivially provide  a conversion of the kind you describe would be more work for implementers, would force authors to duplicate work that the UA has already done, and would be more complex to specify. I'm sorry, what was the expected value we would get for that?

We could expose more things, but no one asked for them. If people ask for them, we can expose them in 1.1. It's not complicated.

Robin Berjon - http://berjon.com/
Received on Monday, 30 November 2009 13:43:30 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:21 UTC