From MemberWiki

URL: /member/wiki/Interoperability_Minutes_2008-11-13

Contents 1 Attendees 2 Minutes 2.1 Review decisions from F2F 2.1.1 Original Agenda 2.1.2 Resolutions 2.2 Regular phone call time 2.2.1 Resolutions 2.3 Providers 2.3.1 Original Agenda 2.3.2 Detailed discussion 2.3.3 Resolutions 2.4 scope param to subscribe(), also filter and subscriberData 2.4.1 Original Agenda 2.4.2 Detailed discussion 2.4.3 Resolutions 2.5 PMEs: Properties/methods/events 2.5.1 Original Agenda 2.5.2 Detailed discussion 2.5.3 Resolutions 2.6 Latecomer widgets missing earlier events 2.6.1 Original Agenda 2.6.2 Detailed discussion 2.6.3 Resolutions 2.7 states 2.7.1 Original Agenda 2.7.2 Detailed discussion 2.7.3 Resolutions

Attendees

• Jon Ferraiolo, IBM
• Bertrand Le Roy, Microsoft
• Kin Blas, Adobe
• Eduardo Abe, ILOG
• Suresh Chari, IBM
• Rama Gurram, SAP
• Ted Thibodeau, OpenLink
• Javier Pedemonte, IBM
• Matthias Hertel
• Howard Weingram, TIBCO

Minutes

Review decisions from F2F

Original Agenda

Everyone gets a chance to review resolutions from face-to-face:

• Drive towards completion of OpenAjax Hub 1.1 and OpenAjax Metadata on a fast track, with weekly phone calls to discuss open issues, and shoot for early 2009 finalization and approval.
• Push the “mashable widgets” features found in OpenAjax Metadata into a separate supplemental specification so that the mashup features do not slow down completion of Hub 1.1 and Metadata.
• Work towards reconciling OpenAjax mashable widgets with Google Gadgets to achieve specfication alignment to be as close as possible, while living with the constraints that many of the widget features in OpenAjax Metadata will not be changed because they are already supported in commercial products (e.g., Adobe Dreamweaver and IBM Rational Developer).
• Soon before finalizing OpenAjax Hub 1.1, we will rename it to OpenAjax Hub 2.0. (We will hold off on the renaming because the brand “Hub 1.1″ is used quite a bit in industry, and we think changing the name at a later point will minimize confusion in the industry.)

Resolutions

Everyone was OK with the face-to-face decisions listed above

Regular phone call time

Resolutions

Monday 11am US-PT, starting on Nov. 24. If Howard can't make it (jury duty), then we'll have a subsequent call to review discussions with Howard on Tuesday Nov 25 at 8am US-PT.

Providers

Original Agenda

• What we have now: inline, smash/FIM
• What we definitely need: postMessage
• What we might need: window.name
  • For IE to prevent clicking sound
  • But Google Gadgets might have alternate approach to prevent clicking
  • And we have to make sure we can implement this protocol in a secure and performant manner
• Javier and Jon think we should drop plug-in provider approach, at least from this release.
  • Adds too much complexity. For example, here is the sort of thing we would need to address:
    • Properly define APIs for configuring the provider in a generic fashion
      • i.e. should not have to call smash.prepareForLoad()
  • Other communication techniques need to share larger portions of "SMash" (FIM) provider logic anyway
  • Gadgets has a pseudo class hierarchy approach that addresses extensibility requirement

Detailed discussion

Howard: I definitely believe window.name has security problems. Can redirect the window. I don't trust it.

Jon: I haven't studied it yet, so I can't agree with you yet. But assuming you are right, do we leave it out, or put it in with a big warning about how this has security problems?

Howard: Leave it out. The whole point with Hub 1.1 is security.

Howard: I have an implementation of postMessage(). Not yet complete.

Jon/Howard: postMessage() is preferred. The exact right solution when available in browsers.

Howard: Research papers show that postMessage() is secure.

Javier: Do we want to put postMessage under same pfishing logic?

Howard: Still makes sense to have anti-pfishing

Howard. Current method might not be most efficient for frame pfishing protection for postMessage(). I'm not sure whether the frame pfishing needs to be tightly integrated with the transport mechanism.

Jon: Javier and I want to drop the plug-in provider approach.

Howard: I'm tempted to say I disagree. Message parsing scheme may need to take more responsibility. Better to have a container abstraction vs a provider abstraction.

Jon: Yes, agreed. For example, what if a browser implemented Crockford's <module>.

Howard: Yes.

Javier/Jon: Yes, we were thinking the same thing, but using different words.

Howard: Probably simpler to have a plugin approach for containers.

Javier: For inline, create a DIV. For other, create an IFRAME.

Howard. Yes (talks about how event code might jump around and config info about providers and clients might be scattered around)

Javier: If you have an example or pseudo code, please send it out. The IFRAME stuff is all in the Smash provider now. PostMessage then becomes an IF statement within the smash provider. If so, does plugin interface still make sense?

Howard: Yes. EG maybe Google or SAP might want their own container.

Javier: Jon says that Gadgets does subclassing instead

Howard: That's totally legitimate. I would be OK with that.

ACTION JON/JAVIER: Make a concrete proposal before next phone call

Resolutions

Discussed on 2008-11-13. Left open pending a detailed proposal.

• Agreement to see if we can get around clicking on IE without window.name.
• Concern window.name cannot be made secure.
• OK to replace plugin provider approach with a subclassing approach like what Gadgets is doing. Action on Jon/Javier to submit a concrete proposal for next phone call.

scope param to subscribe(), also filter and subscriberData

Original Agenda

• Any others from 1.0? (i.e. 'subscriberData', 'filter') - Raise this as an ISSUE

Detailed discussion

Jon: In working with the InteropFest I discovered that scope was absolutely needed. Almost can't work without it. You usually have to do something like dojo.hitch when creating a widget.

Howard: I would add it as a 3rd optional parameter.

Matthias: Need a reference to the function object. Like what jQuery does.

Howard: Yes. We are adding it back in now.

Howard: We don't need subscriberdata or filter. Strong opinion we don't need filter. Weaker opinion about subscriberdata.

(discussion about subscriberdata can be done with closures and filters can be included in the handler)

Jon: Main reason for wanting these two is for backwards compatibility so that Hub 1.0 via OpenAjax.hub.subscribe and 1.1 via connHandle.subscribe() look similar to developers.

Jon: filter is 4th, subscriberdata is 5th

Howard: Get rid of them both.

Jon: What about compatibility argument?

Howard: Deprecate them in Hub 1.0 APIs.

Jon: Great idea. I like it.

Howard: Should include notes about how to do filters and subscriber data.

Howard/Javier/Jon: +1

Jon: Any disagreements?

(silence)

Resolutions

RESOLUTION 2008-11-13:

• Add 'scope' parameter to connHandle.subscribe(), but don't add filter or subscriberData
• Put note in Hub 1.0 API section to say that filter and subscriberData are deprecated
• Add text in spec to talk about how to achieve filters and subscriberData using other techniques

PMEs: Properties/methods/events

Original Agenda

• Google Gadgets supports all three
  • Events: pubsub similar to what we have
  • Methods: They have an RPC mechanism
    • There are named interfaces (aka features) that some widgets provide and other widgets invoke.
    • Container links providers with invokers
    • To invoke, issue an gadgets.rpc.call(...,callback) function
  • Properties
    • Via Gadgets preferences
    • We put properties at a higher level (within metadata spec)
    • Gadgets is monolithic so they don't separate runtime versus container
• Do we need all 3 also? (Probably not for 1.1, but let's discuss)

Detailed discussion

Howard: Remote methods are really two-way events. Let's do this at Gadget level. Since we don't have notion of Object, doesn't make sense to talk about methods

Jon: Yes, my analysis too

Jon: Let's consider this for a future release

Howard: Yes, 3.0

Rama: Does't this make gadgets tightly coupled?

Howard: Doesn't have to be tightly coupled. To implement this feature, we would have to figure out how to integrate with security mechanisms.

Jon: Yes, a significant effort.

Howard: Not for this version

Rama: Agreed

Jon/Howard: Regarding properties, lots of ways to do saved state. Don't need to do this right now.

Jon: At this point, state is managed by the container.

Howard: Hub only notifies when state changes

Howard: At some point we will want to tag publishers. But now right now. Would allow putting properties with publisher, such as quality of service

Jon: Agree

Resolutions

RESOLUTION 2008-11-13: Don't pursue Hub-level properties or methods with Hub 1.1 - too complex, not absolutely needed, lots of issues. Remote method invocation (2-way pub/sub) is something to consider for a subsequent version.

Latecomer widgets missing earlier events

Original Agenda

• Could be addressed via properties, where we tell developers that if their message might be of interest to latecomers, then define the event via the <property topic="whatever" publish="true"> element

Detailed discussion

Howard: This is the problem where different widgets load at different times, and you can't be sure of the order in which widgets will be loaded.

Howard: Too many ways to address and different situations have different requirements. For now, treat as an application level problem.

Javier/Rama: Agree

Jon: How would you suggest this problem is solved in the following case: you have a location widget and a mapping widget and you can't be sure the mapping widget comes in later after a location is chosen.

Howard: Have the map widget show a default location until the location widget gets a click. Not automatic but understandable. Another approach is a central component within the page.

Howard: We can add more functionality in the future. Right now, we have lots on our plate.

Jon: Agreed, but this is another topic for a tutorial or primer

Resolutions

RESOLUTION 2008-11-13: Don't pursue anything in Hub for Hub 1.1. Must be solved at application level. Should talk about this issue and candidate techniques in primers or tutorials.

states

Original Agenda

• Howard said something at F2F about Hub having a cleanly defined notion of application state or widget state
• Howard, do you remember what this was about?

Detailed discussion

Jon: Howard mentioned something about making sure the spec was clear about processing model and states, but I forgot the details.

Howard: One key area is within a client inside an IFRAME. What happens if you connect, then immediately connect again, or disconnect and reconnect immediately, where there is async. Need to have a finite state machine that lists the possible states the client can have and what should happen if the client attempts to do particular things when in that state.

Jon: Yes, we need that, thanks.

Howard: Important when callbacks start destroying things, especially in the inline case.

Resolutions

Discussed on 2008-11-13. Left open pending detailed proposal. We need to clearly define a finite state machine for widget lifecycle to cover case of connect();connect(); and things like that. On both client and server.