Gadgets Minutes 2008-01-23

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Gadgets_Minutes_2008-01-23


  • Stewart Nickolas, IBM
  • Howard Weingram, TIBCO
  • Jon Ferraiolo, IBM
  • Frederik De Keukelaere, IBM


(Stew gave a demo via webcast of the latest version of the code he has checked into the open source project. The demo showed a mashup application that supports a variety of "widgets", including Google Gadgets, Apple Dashboard, Yahoo Pipes, dojo, and ext.js. Probably others, also, he talks fast, but that's all I remember.)

Stew: I have learned a lot from building out my mashup application. It uses the Hub and the OpenAjax Metadata spec. Has a list of widgets that are built into the mashup application. A Google Maps widget, a dojo widget, an Ext.js widget, Apple Dashboard that works in an IFRAME, Google Gadgets that works inline via a transcoder, also Yahoo Pipes widget.

Stew: In next couple of days, will post demo on server.

Stew: The demo should work on your system if you post the hub11/ and gadget/ folders in parallel directories on your PHP server.

Stew: Has a view source feature where you can see the OpenAjax Metadata used for each widget.

Stew: Cheated a bit with Dojo for now. The app itself uses Dojo, so the Dojo widgets are using the Dojo that comes with the mashup app. Will fix that later. But the Ext.js widgets aren't cheating. (Note: the current code used <resource> element rather than the OpenAjax Metadata spec's <required> element.)

Stew: Widgets can be added to the canvas and resized. There is UI for identifying which properties are published and subscribed. Has ability to persist the current settings for the widgets.

Stew: Ultimately will support widgets in an IFRAME and widgets in a DIV (i.e., splice mode). Now, most?some? of the widgets are using splice mode.

Stew: Problems discovered. If publish=true and listen=true, might have loops.

Howard: If there is a publisherID mechanism, then many loop situations can be prevented. Hub 1.0 has logic to prevent loops by counting levels of recursion.

(Howard adds: the publisherID could be an optional string parameter to hub.publish(). A gadget or other component that both subscribes and publishes on the same hub topic can optionally ignore messages published by itself. As I noted in the meeting, however, that only prevents cycles of size 1. Cycles of size >= 2 are still possible and this does nothing to help with such situations. I included a loop breaker in my reference implementation for OAH 1.0, but loop breaking after the fact is a last resort; it is better for the application level to prevent loops in the first place, instead of relying on the messaging layer to abort after a fixed number of cycles.)

Jon: My thinking is that publisherID is a requirement for Hub 1.1.

Howard: Our metadata might also help the host application to prevent loops.

(Howard adds: Specifically, I was considering the following. Ultimately, to detect and prevent cycles it is necessary to have a graph consisting of the union of the set of "wires" between gadgets and the set of "internal wires" within the various gadgets. What I was thinking here was that it might be feasible to declare the internal wires. Suppose that a gadget subscribes to X and publishes on Y. Suppose that an event received on X causes state changes in the gadget that have the potential to cause an event to be published on Y. The gadget could declare, in metadata, that an event on X has the potential to cause an event on Y. While performing wiring, a framework could check to make sure that adding a given "wire" will not complete a cycle.

I have not thought through all of the ramifications of this approach yet. It might be overly complex; and in fact, most application developers may simply not care very much about cycles. But I have a hunch that many will stumble in this area unless we provide either guidance or a solution or both.)

Stew: Should each gadget listen to "*"?

Howard. No, don't want that.

(Howard adds: specifically, Stew was asking, should each gadget listen to "*" by default.

I responded "no" for 2 main reasons: 1. subscribing to "*" would open the gadget up to receive anything that is published on any matching topic. Since other widgets on the page will almost certainly publish stuff on a matching topic that is meaningless to this subscriber, and which might even break the subscriber, we should not (by default) subscribe to such a broad topic. Better, by default, to not subscribe at all.

2. Security best-practices call for opening only addresses/ports/channels/topics/etc. that are actually needed. By default, don't listen at all.

Note: please avoid one-token topics, even for example purposes; best practice, which we should promote, uses topics of the form* or org.openajax.something. Otherwise we will run into collision issues. To subscribe to all topics, regardless of the number of tokens, use ** rather than * ).

Stew: OK, when listen=true, you are saying that you might listen to that particular topic.

Stew: Does it confuse or help to have publish=true and listen=true work on the same topic? If there were different topics, might make mapping easier.

Jon: Thought we designed our current approach to match Google Gadgets.

Howard/Jon: Could have publish=topicname, listen=topicname.

(decision: leave the syntax alone for now)

(decision: the public/subscribe metadata indicates that you *might* publish to or subscribe to the given topic, but doesn't result in any auto-publishing or auto-subscribing. All publish and subscribe must be done manually)

Stew: For Google Gadgets, still need to do some of the heavy lifting. Language expansion and macro expansion aren't implemented yet. Probably need different implementations of _IG_Prefs for different persistence mechanisms. Not yet in source code.

Stew: Right now persistence mechanism uses microformats using SPANs.

Jon: Where is the information persisted?

(long discussion on persistence mechanisms, whether to use gadget's native persistence engine or emulate APIs in order to store persistence information using OpenAjax approaches)

Stew: Some customers will want to control persistence

Howard: Sometimes dangerous. I am quite worried. Implementation might depend on its own logic. Might have side effects.

(Howard adds: Specifically, the persistence mechanism used by a gadget framework from, say, Google, might contain side effects or other behavior and it is highly risky to base a solution on replacing such an implementation with a container's own persistence mechanism. The basic solution & standard need to avoid doing this. Instead, the basic approach should be to wrap whatever the gadget and gadget framework do under a standardized interface that allows the mashup framework to access preferences. Adding an underlying persistence provider interface that gadget toolkit vendors can code to in order to store preference info in an external mashup framework is fine, but we must not expect this to work with all gadget toolkits.)

Jon: Maybe we need to have it both ways. Allow widget to do its own thing if it wants, but also provide a path towards a standard persistence mechanism.

Howard: That would be fine.

(Howard additional comment: standard persistence provider interface may represent an unnecessary complication for v1; should be candidate for v1 but might be okay to push this out to v2. Keep standard as simple and focused as possible @ 1st, to make it easy to learn/use.)

Personal tools