Re: [widgets] Interface published

[Kai Hendry]

2009/11/30 Robin Berjon ro...@berjon.com:
  widget.getItem(name) Revolutionary? Well, if you're in business selling
 keyboards and RSI relief, maybe.

I thought it might save on DOM pollution. I have been playing with a debugger
and the global vars passed between the Web runtime and debugger are
outrageously bloated.

 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!

Loads of PHP developers write something like:

?
$s = simplexml_load_file(rawurlencode(config.xml));
echo json_encode($s);
?

Though it looks pretty darn ugly.

 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.

Well it is complicated when you think you have to wait until all the people
upgrade to the next version in order to expose something new.

Though, I can't think of a Debian package that relies on the
debian/control file for anything during runtime.

Please consider my comments as resolved.

Re: [widgets] Interface published

[Robin Berjon]

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:

  widget.name

you have:

  widget.getItem(name)

and instead of:

  widget.aplixExtension

you have:

  widget.getItem(aplixExtension)

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/

Re: [widgets] Interface published

[Marcos Caceres]

On Thu, Nov 19, 2009 at 2:03 PM, Kai Hendry hen...@aplix.co.jp wrote:
 http://git.webconverger.org/?p=faq;a=commit;h=1f335b2997aedb034ca92d06bf815c623939179e

 Please forgive the informal prose.


Yeah, like we are soo serious here! :P If it makes you feel
better, I'm responding to your email in my pajamas :)

But yeah, lets keep it professional.





 This late rant is prompted by [Widget interface spec (Last
 Call)](http://twitter.com/widgetspecs/status/5799561554).

 Widget APIs or rather [Widgets 1.0: The widget
 Interface](http://www.w3.org/TR/widgets-apis/) is largely about exposing 
 what's
 defined in the widget [configuration
 document](http://dev.w3.org/2006/waf/widgets/Overview.html#configuration-document)
 to the Widget developer.

 **WHY?** You may rightly ask. The widget developer should know his own name 
 and
 email address whilst writing a function to mail him a [bug
 report](http://www.w3.org/TR/widgets-apis/#metadata-attribute-values). I guess
 someone has argued that slapping new `widget.` attributes makes it easier for
 library developers. [BONDI](http://bondi.omtp.org/) incidentally rightly 
 (imo),
 didn't bother with this mapping.

I agree. Accessing all the config file metadata is kinda pointless.

 Another reason WHY pointed out by
 [robin](http://twitter.com/robinberjon/status/5825994237) is that the simple
 Widget interface exposed by the widget runtime, would implement
 [locale 
 support](http://dev.w3.org/2006/waf/widgets/Overview.html#locale-folder0)
 and give you the localised interface. I.e. it's doing a bit of work behind the
 scenes for the convenience of Widget developers and well...  non-English
 speakers. However again, one can argue that Widget developers can implement
 their own locale support, which isn't that hard (they have probably done it
 before), but it would probably suck.


This is true. One is certainly free to do that, but I don't know why
you would if you get it for free in widgets.

 Ok, in an 
 [example](http://dev.w3.org/2006/waf/widgets/Overview.html#configuration-document)
 Widget configuration file, like `config.xml`, you might find:

        widget xmlns=http://www.w3.org/ns/widgets;
 id=http://bondisdk.limofoundation.org/widget/webcmd; version=0.4.2
 viewmodes=fullscreen

 Which maps onto the [Widget interface](http://www.w3.org/TR/widgets-apis/) as:

        widget.id = http://bondisdk.limofoundation.org/widget/webcmd;;
        widget.version = 0.4.2;

 Though what about viewmodes? Hmm...

Viewmode attribute would be defined by the viewmode spec. Viewmode
also relates to CSS.

 Then:

        name short=WebCWeb Commander/name

 Maps as:

        widget.name = Web Commander;
        widget.shortName = WebC;

 Ok, the attribute `short` was used as a prefix to `name` which has
 become capitialised in order to make it easier to distinguish. Ok,
 fine. However this is there is _an inconsistency_ with:

        author href=http://bondi.limofoundation.org/;
 email=s...@bondisdk.orgLiMo Foundation/author

 Maps to the Widget interface like so:

        widget.author = LiMo Foundation;
        widget.authorEmail = s...@bondisdk.org;
        widget.authorHref = http://bondi.limofoundation.org/;;

 Now the author element attributes like `email` and `href` become
 suffixed to `author`. You see how `shortName, should be **nameShort**?

do'h! Might not be too late to change that. We will put in on the
agenda for discussion. I need to check who has implemented that so far
(if anyone!). If no one has implemented, then I will change it.

 Other elements can be found on the `config.xml` such as:

          feature name=http://bondi.omtp.org/api/ui; required=true/
          license href=http://bondi.omtp.org/BONDI-LICENSE-2.0//
          content src=index.html/
          feature name=http://bondi.omtp.org/api/appconfig; required=true/
          feature name=http://bondi.omtp.org/api/filesystem; 
 required=true/

 However there is no mapping to the [Widget
 interface](http://www.w3.org/TR/widgets-apis/). Who decides what gets mapped
 and what doesn't? Wouldn't it be simpler and more consistent to just map
 everything?

No.
Re: license, see:
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0515.html

Features, if they are APIs, are made available as defined by their
respective specifications (e.g., on the Window object).  And you are
looking at the content already (document.location).

 It does get tricky especially thinking about the possible multiply
 nested http://dev.w3.org/2006/waf/widgets/Overview.html#the-param-element.

 Also some punks might overload the `config.xml` with  _openURL_ which
 would clash.

No, openURL is spec'ed to ignore relative references.

 I understand some elements like the [feature
 elements](http://dev.w3.org/2006/waf/widgets/Overview.html#feature)
 and undefined (proprietary) elements like:

        access network=false localfs=false remote_scripts=false/
        billing required=true/

OMG! What's that billing 

Re: [widgets] Interface published

[Kai Hendry]

Some comments:
http://dabase.com/blog/Widget_mapping_quirks/

Do I need to send them inline? I do prefer the Web since I can keep it
better upto date.

Kind regards,

Re: [widgets] Interface published

[Robin Berjon]

On Nov 19, 2009, at 14:37 , Kai Hendry wrote:
Some comments:
 http://dabase.com/blog/Widget_mapping_quirks/
 
 Do I need to send them inline? I do prefer the Web since I can keep it
 better upto date.

Right, but the problem is that you can change them after we've formally 
addressed them, which is a bit problematic. If you want to keep them on the 
web, could you make a stable dated version available?

-- 
Robin Berjon - http://berjon.com/

[widgets] Interface published

[Marcos Caceres]

Hi all,
Widget interface spec ready for publication (Last Call) [1]. Will be out 
sometime today (if not already published).


And test suite files are now online [2].

Enjoy in moderation!

Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/widgets-api/
[2] http://dev.w3.org/2006/waf/widgets-api/test-suite/