Gadgets Minutes 2009-03-09

From MemberWiki

Jump to: navigation, search

URL: /member/wiki/Gadgets_Minutes_2009-03-09

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Rama Gurram, SAP
  • Lucian Cozma, Adobe
  • Kin Blas, Adobe
  • Eduardo Abe, IBM/ILOG
  • Stew Nickolas, IBM
  • Javier Pedemonte, IBM
  • Dan Gisolfi, IBM
  • Adam Peller, IBM
  • Rich Thompson, IBM

Minutes

(Reviewing /member/wiki/OpenAjax_Mashable_Widgets)

Introductions

Stew: There are a whole series of issues regarding the widget spec and mashups. We have taken a stab at solving how to support mashup scenarios. Features around lifecycle and APIs. What's the role of the wrapper and the mashup app.

Stew: I'm Stew, led the Gadgets TF last year

Jon: I direct things at OpenAjax Alliance and I'm co-chair of the IDE WG

Eduardo: I work in the ILOG part of IBM. We have components, mostly JSF. There is interest in ILOG to make use of OpenAjax interoperability and integrate into our components

Javier: I've been working with Jon on OpenAjax. I was part of the team that worked on the reference implementation for widgets

Rama: I'm in SAP Labs that is part of research. Working on Enterprise mashup technologies. Want mashup framework and ecosystem around widgets. We demonstrated a prototype at the InteropFest

Jon: SAP's prototype included Hub 1.0 and support for the widget format as it stood back then

Rama: We are very interested to see widget APIs and reconciliation with OpenSocial

Lucian: I work with Kin. Interested in opportunities for mashable application framework.

Kin: I work on Dreamweaver.

Dan: I'm in Emerging Technologies in the IBM SWG. I focus on mashups and widgets and help to evangelize all of OpenAjax. I work a lot with customers and partners.

Adam: I am working on a reference implementation of the widget format, a new version based on the latest specs

Jon: Adam's implementation is 100% JavaScript. We hope it will be useful across the industry.

Rich: I have been on a specification effort for IBM's internal widget format

General discussion of mashable widgets wiki page

Stew: Has everyone looked at it? We can start with the markup and then go to the APIs

jsClass

Stew: Proposal is to keep it. But change the constructor to an empty constructor.

Stew: Any objections to keeping it?

(no objections)

RESOLUTION: Keep jsClass

sandbox

Stew: This is a hint to the mashup app whether the widget should be sandboxed. We have various hints. Mashup app might put everything into IFRAMEs if it wants

Stew: Any objections to keeping it?

(no objections)

RESOLUTION: Keep sandbox

scrolling

Stew: Hint on how/where to put scrollbars. Intent is to avoid double scrollbars

Rama: Do we need vertical or horizontal scrolling control?

Stew: The spirit is like the 'overflow' property in CSS. You get h or v or both if you need them.

Jon/Rama: Sounds good

Adam: Why can't it use CSS?

Stew: It is a widget indicator to the container

Adam: Doesn't widget have access to the DIV?

Stew: In the IFRAME case, you have adornments in a different document

Adam: Now it makes sense

Stew: Any objections to keeping it?

(no objections)

RESOLUTION: Keep scrolling

singleton

Stew: Hint that this widget should appear only once on the canvas. An example, a directory gadget or a developer gadget. Default is false.

Javier: Is this a must or should on the mashup app?

Stew: My feeling is this is a must. Could be destructive to itself or the mashup

Rama: We are using singleton. We also had an attribute called designtime. When in runtime mode, not active. Probably good to put this into the spec temporarily with a note as a reminder even if we decide not to include it in the first release. Causes the widget to be hidden at runtime. Only shows at designtime.

Jon: I'm inclined to add such an attribute. A mashup app doesn't have to honor it. But better to share the markup across products.

Stew: Have you seen something like this?

Rich: Key question: if you want to put a Company-A widget on a Company-B mashup. I think most of the time the answer is authoring tool specific.

Jon: Rama, are your design time widgets tied to your environment?

Rama: Partly. More or less framework-specific.

Rich: Good to capture this attribute with a likely resolution of "no". Would be good if there was a registry shared across tools.

Stew: I agree for now to namespace it. I agree designer widget usually are canvas-specific.

Rama: Where do we put this attribute?

Stew: You can have an sap:designtime attribute in the sap: namespace. For example, sap:designtime="true"

Rich: There will be some extension attributes that are implementation specific or advanced features for future versions of the spec

Kin: Is there an architecture document that describes what is in a widget?

Stew: We have some pictures from the Gadgets TF last year. I'll take the action to create architecture pictures

RESOLUTION: Keep singleton

RESOLUTION: Add 'designtime' attribute to spec, but likely to say 'no' to that attribute for first release

type attribute

Stew: Values now are 'fragment' and 'page'

Jon: Why use a different set of keywords from OpenSocial? They use 'html' and 'url'.

Stew: Right, we started that way.

Kin: How does this relate to sandbox? If sandbox=true and type=url, do you get an iframe in an iframe?

Stew: No, only one iframe

Javier: One thing to note. If type=page, various markup is ignored. Sandbox is one of the things that can be ignored.

Stew: Yes, you are an external object. Resource inclusion, such as require, are not applicable.

Javier: In spec, we need to add a list of things that are ignored when type=page

Stew: type=page says I'm taking control of the iframe (widget is saying this)

Stew: Any objections to html/url?

Rama: Can URL point to XML or JSON?

Stew: You can include SCRIPT element that deals with JSON. Regarding XHTML vs HTML, content is HTML

Kin: 'src' attribute says content is external. Does type indicate what type of external?

Stew: Yes

Kin: Question about 'url'. Does that mean full page?

(discussion about how OpenSocial names are misleading)

RESOLUTION: Keep existing names (i.e., type=fragment|page)

'view' vs 'mode'

Stew: Our proposal is to drop 'view' and add 'mode'

Jon: The realization is that our 'edit' and 'help' features are different things than what OpenSocial is doing with 'view'. Orthogonal. We can add an OpenSocial-compatible 'view' in the future, but let's not do it now.

Javier: Custom display modes?

Jon: Yes, that's right

Stew: It is the container responsibility for changing modes and informing the widget

Stew: Any objections to dropping 'view' and adding 'mode'?

(none)

RESOLUTION: Drop 'view' and add 'mode'

type=page

Jon: Complex discussion. How does type=page work, particularly when changing modes. The widget is in charge of the rendering. How does the mashup app managed to cause a mode change?

Stew: What helper mechanisms do we provide? For example, how to we provide property APIs to a widget with type=page?

Rama: How do you support Flash? type=flash?

Jon: No, the content is always HTML. You can use Flash by have the HTML content include an EMBED or OBJECT tag

Further edits

Stew: Please add your comments to the wiki page using color-coding.

Next phone call

Stew: Does this time slot work for everyone?

(no objections)

Stew: OK, keep this time slot

Personal tools