Interoperability Minutes 2009-10-26

From MemberWiki

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-10-26

Contents 1 Attendees 2 Minutes 2.1 Open source changes to Hub 2.0 reference implementation 2.2 OpenSocial proposals 2.2.1 Wiring metadata 2.2.2 Protocol versioning 2.2.3 Anonymous pubsub 2.2.4 Tunnel iframe in postMessage 2.2.5 Locked domain 2.2.6 Feature name of "PubSub" 2.2.7 Instance based APIs 2.2.8 Cleanup of lost objects 2.2.9 Manager APIs 2.2.10 States and managed properties 2.2.11 Future phone calls

Attendees

• Jon Ferraiolo, IBM
• Matthias Hertel
• Javier Pedemonte, IBM
• Howard Weingram, TIBCO

Minutes

Open source changes to Hub 2.0 reference implementation

Jon: I spent a couple of hours looking at the changes. They are going in the right direction.

Javier: The SMash low-level classes appear to be reasonably separable, which will make refactoring easier.

Howard: I wanted to confirm - OpenSocial does not conform to Lowe. Also, in current code, to reconnect, you destroy and recreate an iframe, which is not acceptable.

Javier: With current code, that might be true. The code is still a work in progress. First, I'm getting the pubsub code working again.

Howard: Most of my other concerns are in the same vein. OK if this is just a work in progress.

Javier: I have been keeping the security features until later. I'll put it in once so it applies to all three transports.

Howard: OK

Howard: I like the way you are organizing the objects and layers

Howard: Are we replacing FIM with RPC?

Javier: Not yet. That would happen in a second stage. There are some security and backwards-compatibility issues that we would have to address with RPC. I expect we will want to have backwards compatibility.

Jon: Also, there are a couple of security things we would need to add to RPC.

OpenSocial proposals

Proposals under development: http://wiki.opensocial.org/index.php?title=PubSub.next_Proposals

Wiring metadata

Jon: For wiring metadata, I changed things to match what Howard proposed in an email yesterday, with two separate attributes, 'type' and 'format'. One change I made. Initially, I was going to propose all of the standard formats and extensibility via URIs as OAMetadata, but leave off the IDE ones, which are length, color, style, class and id. But then I thought color might be good to standardize, and then why not length and style, and maybe sometimes you want class. That left 'id'. I left it in under the thinking it allows to two specs to match even if 'id' doesn't seem very useful in gadget scenarios.

Howard: Are there particular restrictions on the allowable characters in an 'id' version a string.

Jon: Yes

Howard: Then let's leave it in.

Protocol versioning

Howard: We raised that requirement.

Jon: I inserted a placeholder, but didn't write up a proposal. At our last meeting, Fargo said to put that in the "Enterprise OpenSocial" bucket.

Matthias: We should ask why do we need it? Because of extensibility. Otherwise, we are forever restricted to the old protocol.

Howard: The protocol versioning was designed to address the federated case. Different servers for the manager and component, possibly with different Hub code.

Jon: OAWidgets are client-heavy and OSGadgets are server-heavy. With OAWidgets, a company can insert their own version of OAHub into the widget. With OSGadgets, the Shindig server can always inject code that it needs into the gadget runtime. Is the Gadget's injection approach acceptable to the Enterprise world?

Matthias: Reason not to do protocol versioning.

Howard/Jon: Also, the Gadgets guys like to keep things simple

Jon: Here's an idea. Maybe an approach to pursue is to update RPC such that the first token is a versioning token. If the system recognizes the versioning token, then it can pop it and then the rest of the tokens are as they used to be.

Matthias/Howard: A possibility

Anonymous pubsub

Jon: Fargo says they don't need gadget IDs. Howard explained why gadget IDs cannot be useful here:

OpenAjax_Hub_2.0_Design_Comments

Tunnel iframe in postMessage

Jon: Some OpenSocial sites can't deal with tunnel HTML file

Howard/Jon: Needed for synchronous notification of onunload

Javier: I don't see why they can't deal with this. If they have logic to deal with responding to HTTP request for XML metadata, they could add similar logic for tunnel HTML file

Jon: Yes, you would think so

Locked domain

Jon: Is this all at the manager level? Any Hub consequences?

Howard: Manager thing. Hub doesn't care. Hub uses whatever URL the manager is giving it.

Matthias: Why is this needed?

Howard: Mostly for security reasons

Jon: One issue is cookies.

Feature name of "PubSub"

Howard/Matthias: Fine

Instance based APIs

Jon: I looked through my notes from the face-to-face and Fargo agreed. In fact, said instance-based might be a requirement.

Howard: OK

Jon: Notice my proposal of mimicking MiniMessage and TabSet constructors, with constructor parameter __MODULE_ID__

Jon: Notice that in OAWidgets, your code has to put quotes around __WID__ but apparently Shindig provides quotes around __MODULE_ID__

Cleanup of lost objects

Jon: Javier responded on this topic

Howard: OK, need to make sure this is addressed when spec is done

Jon: We need to add a section to the wiki page on this topic so we don't forget about it

Manager APIs

Howard: There are 2 mechanisms that allow the application/page to communicate with gadgets: 1) a manager API, and 2) using an inline gadget. The manager API is less of a change at the moment, given that inline gadgets are not currently supported.

Jon: They are thinking that Caja will address their inline needs, but even with Caja they may discover they need manager APIs to distinguish between loading a gadget with Caja or not

Howard: At that point, you might as well formalize a notion of containers

Jon: We'll know for sure whether we need Manager APIs in the Gadgets spec once we get deeper into implementation

Howard: We talked about phasing this. First, implement the gadget interface. Then modify the open source in a clean manner that matches what might go in spec. Then maybe later put into formal spec

States and managed properties

Howard: We already have this in OAWidgets. What does Gadgets have?

Jon: UserPrefs, but they might kill that feature, replace with "application data". If app data, then we would want a way to have a portion of app data managed by the container.

Howard: Let's hear from them before making proposals

Jon: Mark might know more

Future phone calls

Jon: Let's do most of our communication on interop@openajax.org. Phone calls on an as-needed basis.