Gadgets Minutes 2008-4-16

From MemberWiki

Jump to: navigation, search


  • Stewart Nickolas <nickolas(at)>
  • Rama Gurram <rama.gurram(at)>
  • Jon Ferraiolo <jferrai(at)>
  • Howard Weingram


  • Widget loading/unloading interactions for static and dynamic widget assemblies
  • Trusted and untrusted models (integrating with SMash)

The interactions diagrams are located on Gadget Loading


From the previous meeting, updated the Gadget Loading with the suggestions from the last call, we plan on completing that review

Howard: Inserting an untrusted widget should just be passed boot strapping parameters on the URL. Deeper level interactions with properties should take place through the Hub. We do NOT want to create another secure communication scheme similar to the OpenAjax Hub.

Jon: Other gadgets/widgets systems use the URL to pass parameter to untrusted widgets

Howard: I'm concerned about the URL limits regarding passing parameter values to the gadgets.

Stew: The google gadgets spec has this limitation, that is the potential to exceed the URL size limit when constructing the URL with the name/value of the Gadget Properties.

Back to the flows:

Stew: The static loading scenarios refer to the fact that system implementing the IDE Widget and Gadget metadata may choose to implement a more optimized page construction model; specifically, caching pre expanded gadget fragments and generating page HEAD sections with SCRIPT, CSS etc. tags.

Stew: This helps optimize the initial page delivery of a page containing widgets, for example, the more traditional IDE model will generate pages in this say.

Stew: We want to make sure implementation can do this (server optimization) so that the initial page load is not "choppy"

Howard: We need to make sure this is simple, we need to avoid complex interactions

Jon: It may be difficult to use the Hub to bootsrap during page loading, for example composited widgets. Google does not have the ability to setup properties after the contructor, all parameters have to pass all the information you need.

Howard: Does this have to be the URL or can it be a script tag?

Jon: During page server you need all the constructors arguments for that widget, the server needs to know the properties, natuaral way is through URL

Howard: If we are going to use the URL, state clearly that its a one shot URL. Also make sure we discuss that this model will have none of the other benfits of communicating via. the Hub during widget construction

Jon: As we look at mapping the widget loading process to other models, we need to make sure we pass enough information on the URL for example when loading google gadgets

Howard:We need to keep this as simple as possible with as few variations as possible.

Jon: Yep, for the reference implementation we can use the URL model with the documented limitation of URL model

Jon: For now lets pass the parameters on the URL

Jon: Are the argument passed to the constructor macro expanded?

Stew: No

Stew: What is the default constructor for widgets? We currently pass the ID and property bag to the widgets.

Howard: This correct, we need to be careful about passing OPTIONAL arguments, the bag works well in this case

Jon: It seems like other gadget systems may have different required arguments, for example Dreamweaver has three default arguments.

Howard: The ID if the widget is fundamental to the system, I feel that should be a standard argument to the construct, I don't mind of the ID is a string.

All: for the widget system we should avoid consulting the widget api metadata, more to the point we shouldn't have to for the functioning of the widget system.

All: We should simply use the default constructor for gadgets, focus on simplicity

Personal tools