Gadgets Minutes 2007-12-12
From MemberWiki
URL: /member/wiki/Gadgets_Minutes_2007-12-12
Contents |
Attendees
- Stewart Nickolas <nickolas(at)us.ibm.com>
- Rama Gurram <rama.gurram(at)sap.com>
- Stas Malyshev <stas(at)zend.com>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Howard Weingram <weingram(at)tibco.com>
- Kevin Hakman <khakman(at)tibco.com>
Agenda
Agenda:
- 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
Minutes
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)
Topics
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")
