Gadgets Minutes 2007-12-12

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Gadgets_Minutes_2007-12-12



  • Stewart Nickolas <nickolas(at)>
  • Rama Gurram <rama.gurram(at)>
  • Stas Malyshev <stas(at)>
  • Jon Ferraiolo <jferrai(at)>
  • Howard Weingram <weingram(at)>
  • Kevin Hakman <khakman(at)>



  • Continue to review the Proposal: IBM Widgets proposal
  • Discuss the ability to transform other widget definitions into OAA format
  • Discuss initial thoughts and views on a test harness for conforming widgets


Topic: Jon's comparison of Google Gadgets to our format

Stew: Jon added some notes to the wiki page

Jon: I did a comparison as a paper analysis of the alignment between Google Gadgets and our spec to make sure that we will be able to do a lossless transformation. I did this before I saw your XSLT script.

Properties, publish/subscribe

Stew: I didn't want to do a union. For example, Netvibes has a ranges feature that we probably don't want to attempt to support.

Jon: Makes sense. If we union, we have to keep adding features as new releases come out. For features we don't support, they can be mapped into a private namespace, such as gadgets:author_affiliation

Stew: Yeah, open-ended extensibility is good

Stew: publish/listen - Our spec has good alignment with Google Gadgets. My thinking was to have something simple, targeting ease of use.

Jon: Sounds good.

Jon: Regarding type, defaultvalue, and required, that brings up the point about JSON Schema. Is that something we want to take into account?

Rama: JSON Schema provides more flexibility in defining data

(discussion about XML vs JSON. agreement that in general XML is good for metadata and JSON is good as the format of the message)

Howard: Want to avoid too much formality at this time. Just assume both sides understand the format. Can always add schema later on.

Stew: The proposal has a constraint variable which is designed to address common cases in a simple manner. Not finished yet.

Jon: Constraints can get complicated. XML Schema has a whole module just for that where primitives can be made into a new datatype that includes constraints. Lots of work to recreate that. Note that Google Gadgets has gotten by without constraints.

Stew: The IDE strawman has jsType and xsdType. I was trying to find a balance in between. The goal was to help a property editor. Question about whether this is enough and whether this is a slippery slope. I am hearing negative feedback.

Howard: I suggest leaving it out of version 1.

(discussion about inline property editing and how properties usually are passed to the widget via URL parameters)


Rama: With events, do we need to identify who sees what?

Stew: Have been working with the Hub 1.1 effort in this area. There is an issue with hierarchies. There is a proposal that there is metadata that indicates which events go outside. Either metadata or procedural way to indicate which events go out.

Rama: OK

Stew: Moving down to lifecycle comments. Based on what I heard from Lori from Adobe last week, it appears that IDEs are quite different in that they just hold a proxy whereas a mashup inserts a live object.

Kevin: Lori did say that but to clarify it was about the limitations with the current version of Dreamweaver. It appears that DW is the exception. Other IDEs seem to actually place the widget on the canvas in a live manner versus the proxy approach. (Lists some IDEs)

Jon: jMaki also to some degree.

Stew: OK

Initialization and configuration

Stew: Some libraries share initialization and configuration settings. Our spec has requires. Could reference a site that holds a library that can be shared. Seems to align with IDE work.

Howard: Security issues if widget gets its library from its parent

Jon: Yes, very true, but that's not what's being proposed. The idea is that widget gets its library itself, but just identifies the library by toolkit name and version rather than URL. I wrote an email. Complex issue. This is a hot discussion both here and IDE WG.

Stew: Current thinking is that the hosting environment would find the toolkit for the widget.

Predefined/standardized topics

Stew: Last think I noticed was Google's list of pre-defined topics. It is important to have a registry or repository where some topics are managed.

Howard: With the Hub, topics used dot notation. So, not everything has to be in a central registry.

Stew: Would be great if registry had some shorthand constants to minimize typing.

Jon: I was thinking along a different axis. There are a small number of commonly used standard events that we define in the OpenAjax domain as org.openajax.topics.whatever, and then others are free to define their own topics in their own namespace.

Howard: Yes, all for it. But note that if we define topics we also have to define payloads.

Stew: I think we are all on the same page.

Jon: How about just adopting what Google has already defined?

Howard: Need to put those events into a subspace, such as geospatial.

Stew: I like the geospacial idea. Also, financial subspace.

Jon/Howard: Summarize: For Google events, we create our own comparable event at org.openajax.whatever in the form of a spec, but also deliver transcoder from Google to OpenAjax via open source transcoder

Kevin: Yes, will drive adoption by embracing Google. They are big enough to create defacto standards. Note that in the Enterprise space the requirements can be more sophisticated. Financial customers need much more detail than just a simple stock quote. Maybe ok for consumers, but not for enterprises.

Topic: XSLT transform

Stew: At the bottom is a small XSLT to convert Google Gadgets into our format. Will submit to open source project tomorrow.

Topic: Test harness

Stew: We have some code that does client-side wiring using (sort of) Hub 1.1 in JavaScript

Stew: Gets to question about the role of a reference implementation. My thinking is that initially this is used to drive discussion. Maybe later it can be adapted to help with conformance.

Howard/Jon: Sounds good.

Topic: Next meeting

Stew: Next meeting in January.

Jon: I think the big thing now is to reconcile differences between IDE WG and Gadgets TF.

(Kevin/Stew agree)

(more discussion of "widget" vs "gadget" vs "control")

Personal tools