*** I have cross-posted this to both lists as kind of a summary of the results of the curiosity of how useful the Widgets 1.0 spec will be for WebOS. The full forked thread can be accessed at <http://lists.w3.org/Archives/Public/public-appformats/2007Feb/0101.html> ***
> 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?
On re-reading the definitions given, any data could be considered 'preference data' I suppose, as long as being included there does not mean it must be included in some auto-generated preference form :)
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?
More like the floating <div>. It was just a thought, but sometimes one might want to ask the user for data (or display extra data to the user) not in the widget. For settings or showing the contents of an RSS item, for example.
> 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.
Ah, so the draft is more fluid at this point than I had perhaps thought :)
Web widgets (widgets that are embedded into web pages, like live.com widgets, 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.
Alright, this makes sense. The spec is not really meant for web widgets but the file format part could be adapted to mostly work :)
