Gadgets Minutes 2007-11-16

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Gadgets_Minutes_2007-11-16



  • Stewart Nickolas <nickolas(at)>
  • Rich Thompson <richt2(at)>
  • Rama Gurram <rama.gurram(at)>
  • Stas Malyshev <stas(at)>
  • Jon Ferraiolo <jferrai(at)>
  • David Boloker <boloker(at)>


  • Introductions and Logistics
  • Initial discussion of the goals of the task force
    • Strawman: "Enable application developers and assemblers to create composites of loosely assembled pre-packaged application gadgets from a variety of Gadget Systems"
  • Discussion of activities that OpenAjax might pursue in support of the goals
    • What is a Gadget/Widget? (, start here?)
    • Define a set of usage scenarios that embody the goals
    • Define a shared specification for Gadget Metadata
    • Provide a reference implementation and mapping to member toolkits
    • How does this effort relate to other Task Forces and Work Groups within OOA
      • IDE Work Group, shared metadata
      • OpenAjax Hub 1.1, communication channel between widgets
      • Security Task Force, embody best practices and secure communication
      • OpenAjax Registry, expanded role for assisting widget assembly (e.g. widget toolkit registration and factory)
      • Mobile Widgets
  • Moving forward
    • Wrap up, next steps
    • Date/time and frequency of the calls



(Stew asks everyone to introduce themselves)

Stew: I work on QED

David: IBM, have been doing a lot in area of mashups

Rama: SAP Labs, Advanced Technology. Have been looking at Web Widgets - Enterprise, and security aspects. Not desktop widgets but more like QED. Mashups in Enterprise space. HTML widgets. Mashups that are cross-domain.

Stas: Zend Technologies SW Architect. Working on project that prototype efforts. One project is around Web Widgets for PHP.

Rich: IBM. Have been looking at area of content aggregation for about a decade. Have been looking into standards for federated things on server side.


Stew: I'm going to describe how we got here. At F2F we decided to define a widget model, looking at existing gadget providers. There are many and there will be many. How do we describe widgets in a way that allows gadget assemblers to assemble things into a mashup. Mainly the browser canvas, but doesn't preclude other use cases. We identified some key characteristics:

  • Co-existence so widgets can share a space, not collide, communicate via OpenAjax Hub
  • Communicate in a secure way, such as via Hub11 and SMash
  • Key thing for us is metadata that describes PMEs (properties, methods, events) so that they can be consumed by the composition platform and able to use widgets from a variety of systems
  • Security is an important aspect of this. People on call are familiar with SMash techniques. Maybe use IFRAMEs as part of the security approach.

Stew: I sent around an initial strawman that attempts to capture these requirements. Our goal is to enable mashup creator to assembly loosely connected components in a secure manner.

Stew: The efforts in the IDE WG are pertinent. Need to coordinate. Jon has a consolidated proposal and has developed some comparison matrices. I have a strawman proposal for Gadgets effort that is ready for review and am working on an update.

Stew: Now, let's go around the room, get an idea of where you'd like to participate

Jon: I'll start. We are doing lots of things at OpenAjax, but mashups are probably the most important. Mashups represent a revolutionary approach to how applications are delivered where the user builds his own apps without requests to IT dept. Culmination of SOA efforts. So, I'll be giving a high priority to this effort.

(everyone else was silent)


Stew: Let's talk about what we mean by widgets. I am assuming HTML+JS, ie, web technologies. Mainly prepackaged web widgets but also sometimes lower level things such as widgets in Dojo. PMEs are used to enable wiring. Must important thing we are doing is the widget metadata. Our goal is to share the format as much as possible with other efforts such as IDE WG but extend for our needs. IDE WG tends to focus on lower-level controls but not necessarily always. We tend to work on high-level components. We need to coordinate with IDE work. Also need to coordinate with OpenAjax Hub effort.

Stew: In terms of process, we will develop a set of requirements and also write some code. Code always talks. Important to have a reference implementation. For example, SMash includes examples.

Stew: May need to put some things in the Registry, such as information about widget factory, such as this is a Dojo component. What libraries are needed? Is there a central place for dynamic loading?

Jon: I agree with overlap with IDE effort. Need to coordinate with them.

Stew: I agree that markup should be shared by identify extension points for mashup requirements. Some of use are working towards consolidating the two efforts.

Rama: What are we talking about with widgets? Low-levellike calendar or higher-level?

Rich: Historically, there was a difference between controls and sets of logic, but that distinction is now blurring. Calendards are now configurable and moving towards the mashup space. On a collision course with each other. Becoming a continuum. We need to allow a user how is building the page to decide how they are used.

Stew: I agree on the continuum. Need to work with the IDE WG. Also, need events that are published and subscribed.

Jon: Some Ajax toolkits are defining PMEs to allow component integration, but target their efforts to app development, not end user

Rich: Need to make sure our mashup paradigms also work for HTML development

Rama: Need a standard way of representing event payloads

Stew: Interesting area. Google Gadgets has a pub/sub mechanism where events share a common name. Topic name also tied to a data type for saving preferences. Important to have 80/20 or 90/10 approach. Need to have extensibility for more sophisticated payloads. Maybe as far as QNames.

Stew: QED has some standard topics and payloads. Sticks to strings, ints, and enums, with simple lists. Atom feeds to help unify lists.

Jon: Standard date event? Standard lat/long event?

Stew: Our proposal has that exact thing.

Jon: So, we need some standard topics and payloads. Which committee defines these at OpenAjax?

Stew: I asked that question in my proposal. Does it go in the Registry? Kind of makes sense.

Jon: Yes, we need some sort of registry, whether additions to OpenAjax Registry or a second registry. But which committee? I think this committee, which cares about mashups.

Stew: Maybe the Hub.

Jon: Yes, another option is Interop committee.

Rama: How do other pepole define new topics?

Rich: 90% of the time, strings are sufficient. We have used XML Schema for more complex types.

Stew: Need to keep things as simple as possible because of overhead of cross-frame communications.

Rama: Anyone look at microformats?

Stew: Microformats can be used. Some mashups use that, such as hcards and vcards.

Jon: Need to look at generic microformats differently than the specific approaches used by The payload for each topic is a microformat in the generic sense. Some payloads will be microformats as defined by but others will be defined in other manners, such as formal XML grammars defined with XML Schema or something like that.

Rama: Sometimes widgets are on your server, sometimes on a remote server. Any security concerns?

Stew: Yes, very important to support remote servers in a secure manner. Hub 1.1 with SMash is focused on this.

Rich: Also, sometimes you have an intermediate server component. Brings up interesting issues.

Stew: Need to make sure we support server workflows in a reasonable manner.

Stew: Packaging is another thing to consider.

Rama: Are we also looking at server-side mashups?

Stew: As Rich says, sometimes there will be a server component. We are focused mainly on client issues, but want to be aware of server requirements.

Rama: Whata aobut server assembling components?

Stew: Want to support it. Need to allow client assembly and server assembly. Not in scope to pursue a particular server technology, but don't preclude server-side mashups.

Next phone call

Stew: Almost out of time. Let's decide on a new time for the next call.

Jon: Need to avoid Friday 9am. Security meets then sometimes.

Stew: Let's have a standard time.

  • Decision on standard time slot: Fridays, 11amPT, 2pmET
  • Decision on next phone call: Nov 30
Personal tools