[Dojo-interest] microformat for widgets

Mon Dec 26 20:29:48 PST 2005

I'm still wondering what the use is of these web-based distributed, widget systems; I understand the use case of Konfabulator and the Mac desktop widgets, but the Microsoft and Google Gadgets seem to be alot of complexity for not alot of payoff.

 Brad Neuberg

----- Original Message ----
From: Alex Russell <alex at jot.com>
To: dojo-interest at dojotoolkit.org
Sent: Monday, December 26, 2005 19:01:38
Subject: Re: [Dojo-interest] microformat for widgets

On Friday 16 December 2005 8:12 am, Shawn Carnell wrote:
> I'd like to solicit feedback on a microformat that describes widgets.
> We've posted our proposal at
> http://microformats.org/wiki/widget-brainstorming.  Have we captured
> enough data? 

So after looking at the pointed-to page, it seems that I should be 
commenting on this proposal and not the referred URL?:

    http://dev.lawver.net/modulet/profile/

Or did I miss something?

Assuming that AOL ModuleT proposal is the one I'm supposed to be 
responding to, I find it confusing. Firstly, it seems aimed at 
describing components (ala XSD) and not at instantiating components 
inside a page. Is this really the more useful of the two to 
standardize?

Secondly, the ModuleT spec seems to expect that we'll be making requests 
from all over the web for these little self-contained documents with 
references pointing helter-skelter. No mention has been made of URL 
re-writing for the purpose of caching and no protocol for expiry (or 
non-expiry) is specified. Given that they will need to be run through a 
proxy to be integrated into a single document, this will scale like a 
lead brick. 

It's also unclear to me what advantage there is in putting these things 
into their own (X!)HTML containers? What possible good reason could 
there be for expecting authors of the modules to put all their script 
tags in the <head> of a throw-away document and then require tool 
authors to *strip out all of that formatting to do anything useful with 
them*?! Why not just base64 encode it in a <![CDATA[]]> section of an 
RSS feed and call it done? The processing overhead is the same from 
where I sit.

Is this supposed to make things easier to tool? If so, can I see an 
example of what the tools are now that are too cumbersome and how they 
might be simplified by this proposal? The "widget-examples" page 
doesn't really make a compelling case other than to say "here are a lot 
of other ways that this has been solved". And if it's not to make 
things easier for tool authors, what is the benefit for the eventual 
data producers and consumers? If the point is to add new behaviors to 
existing content, the XBL model seems far better suited to the task. If 
it's to add new content to pages, SSI or the document.write() hack 
seems better suited. If it's to agree upon styling, current 
microformats seem a better vehicle.

Lastly, there doesn't appear to have been much thought applied to how 
modules will be processed, developed, or instantiated in this spec past 
what can be done w/ CSS. No attention (that I can discern) has been 
paid to inter-module security, data binding, event dispatch, module 
"subclassing", module localization, or content specialization based on 
context. The examples linked to from the specification give no hint of 
how any of these problems would be addressed by the current proposal.

> Are there things we should change? 

The "Use Cases" of the directly linked-to wiki page needs to outline how 
this proposal deals (or doesn't deal with) the following problems:

    * instantiation
    * tooling
    * authentication/security
    * localization
    * contextual specialization
    * widget "peering" and/or event dispatch

And how the current spec will deal with them *better* than the other 
current proposals.

> All feedback here or on the listservs mentioned at
> http://microformats.org/wiki/widget-brainstorming are very much
> appreciated!

Regards

-- 
Alex Russell
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
alex at netWindows.org  F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
_______________________________________________
Dojo-interest mailing list
Dojo-interest at dojotoolkit.org
http://dojotoolkit.org/mailman/listinfo/dojo-interest