Re: More Widget 1.0 Thoughts

Hi Stephen,
Thanks again for your thoughts...

On 2/24/07, Stephen Paul Weber < singpolyma@gmail.com> wrote:
>
> So I just found the requirements page < http://www.w3.org/TR/WAPF-REQ/ >
> and some things make more sense now.  Doesn't change my earlier
> thoughts, just clarifies some other things.


That document has been superseded. Please see [1] instead.
<http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/>

One question I had was why ZIP is/was chosen?  Why not one of the (I
> am tempted to say more open?) compression formats such as TAR+GZIP or
> just TAR?  Maybe I'm missing something.


All the widget engines that we looked at support Zip (see appendix of widget
reqs for a list of engines we looked at).  Zip is also supported in the
mobile space, so it seems like the logical choice. Also, it is not easy for
a windows user to make a tar.gz files as the format is not natively
supported. That would go against our design goals (particularly ease of use)
and would not meet requirement 3: "Free and Widely Available Packaging
Format".

>From the requirements doc : "The APIs that authors can use to
> programmatically access..."
> Is the list there given considered an exhaustive list of what may be
> treated by the spec?  Much of what is there is not mentioned in the
> draft.  Preferences is a nice thing, but what about non-preference
> data?  Is that to be treated or not?  Is there a place for widgets to
> be able to launch other widgets or dialogs, etc?


The list in not exhaustive and its at risk because of the degree of
divergence in widget APIs. We are trying to define the core of widgets
without interfering with platform specific stuff. Can you please give an
example of non-preference data and why a developer would want to include
that in a manifest? Seems to me that any data would be either downloaded
(using xhr), or put somewhere inside the widget's scripts (eg. an array of
data to populate a drop down list). Also, what do you mean by dialogs? Do
you mean like javascript "confirm()"? or some kind of floating (div) element
with a bunch of options, or the settings (html) files currently by Sidebar?

How is extensibility on this?  Obviously any JavaScript (ECMAScript)
> stuff can be extended by using <script src="..." /> tags to include
> other APIs.  I assume we're allowed to extend the manifest XML with
> namespacing?


Regarding the script element, it depends on the UI language being used.  Not
all widget engines support the HTML DOM.

Regarding extensions through namespaces, maybe. Depends on what manifest
language we come up with.

>From the requirements doc : "The packaging format should support
> optional data compression to make packages smaller." -- the spec
> doesn't make it sound too optional.  Can one just use a folder of
> files then?


A "should" requirements is fairly strong. Please see [2] for a definition of
"should". However, some widget engines, such as Konfabulator, have
experienced issues with regards to performance when dealing with (Zip)
compressed widgets (see flat-file format in [3]). I imagine this is probably
worst on mobile devices.

>From the requirements doc (R20) : "XML is generally excepted and
> understood by..." -- I assume that's meant to be "accepted"?


Woops, thanks! :)

You have documented many desktop-based systems (which I had now come
> to expect from this spec), but you then included AOL Modules...  If
> you are referencing one online system, why not others (such as
> netvibes and live.com) perhaps they're not identical, but they're
> closely related systems.  Again, I may be missing something.
>
> Anyway, just thoughts :)
>

AOL's modules were dropped from the the latest draft of the requirements
document. I know AOL are working on some other widget engine, but I can't
remember what it is called (boxy or something?) We are still looking at
live.com and we may include it in the next release of the document.

Web widgets (widgets that are embedded into web pages, like
live.comwidgets, wordpress widgets, etc) are included into the HTML
without needing
any special security permissions, APIs, and such. Hence, and we can argue
about this, they are not "widgets" as are defined by the widget requirements
document or by the widgets 1.0 spec.  Web widgets are more like "interface
widgets" or interface elements in the classical sense [4] and hence are just
normal parts of a web page. For example, I can make a web "widget" by simply
doing the following inside a html document and adding some script:

<div id="myFancyWidget"> .... </div>

Even if I get my RSS-based configuration for the "widget" through XHR, and
dynamically bind scripts or whatever, it is still just another set of
elements inside a HTML document. Ie. in reality, the browser is still the
same, security model still the same, the web document is still the same, so
there is really nothing new. Hence, IMHO,web widgets are just a kind of
metaphor for widgets that run on widget engines. Widgets that run on widget
engines, on the other hand, do change the security model, do need their own
special APIs, and do have other specific requirements that are beyond web
widgets.

Kind regards,
Marcos

[1] http://www.w3.org/TR/2007/WD-widgets-reqs-20070209/
[2] http://www.ietf.org/rfc/rfc2119.txt
[3]
http://widgets.yahoo.com/gallery/dl_item.php?item=WidgetEngineReference_3.1.1.pdf
[4] http://www-ftp.lip6.fr/pub/distributed_systems/athena/xtk.PS.gz
-- 
Marcos Caceres
http://datadriven.com.au