Interoperability Minutes 2008-11-24
From MemberWiki
URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-11-13
Contents |
Attendees
- Jon Ferraiolo, IBM
- Bertrand Le Roy, Microsoft
- Eduardo Abe, ILOG
- Rama Gurram, SAP
- Ted Thibodeau, OpenLink
- Javier Pedemonte, IBM
Minutes
(Walking through open items at http://www.openajax.org/member/wiki/Hub_1.1_Tasks/Proposals)
Providers/Containers
Jon: Javier sent in a proposal 30 minutes before the phone call:
Javier: Last phone call we decided to change from a plugin provider approach to a class inheritance approach. One change is with createManagedHub. Previously returned a connHandle. Now, returns a managed hub instance. The reason for this is that the class hierarchy made it so that the constructor for the container class needed a managed hub instance.
Javier: Previously, we allowed providers to call the Hub directly. Now, instead of calling the Hub directly, the containers make calls through the managed hub instance.
Javier: This new approach feels nicer and cleaner to me.
Javier: Just as before, there is a getConnectionHandle() API, from which the clients can call connHandle.publish() and connHandle.subscribe(). Therefore, same as before, except underneath it is integrated into the inheritance structure.
Javier: One point of potential contention. Previously, we had a generic OpenAjax.hub.connect(providername,...), where providername was something like 'smash'. In new proposal, you invoke the container's connect API, such as OpenAjax.hub.InlineContainer.connectToParent(). This means client has to figure out which container/provider is in effect and invoke the right connect routine. Jon is leaning towards something more like what we have now, where there is one generic API into which you pass the container name.
Jon: Yes, that's right.
Javier: Doesn't matter much to me.
Jon: Any opinions?
(none)
Javier: Any questions on all of this?
(none)
Javier: Nothing revolutionary, just cleaner
Jon: IMO, Javier has provided a straightforward, detailed proposal towards fleshing out decisions we made at last phone call
Javier: Need to get Howard's input.
Jon: Yes. If no objections, then I suggest going to code
Javier: Yes, we need to see if coding shows any problems
Jon: Right
IE clicking
Jon: Any progress on preventing clicking in IE?
Javier: You thought that Gadgets might have a workaround. They use VBScript for cross-frame communication. I'm not a security guy nor an IE guy, so I don't know if this is secure. Gadgets comments indicate they were thinking about security concerns.
Rama: Would VBScript work in all browsers?
Javier: Only in IE. Gadgets decides which technology to use based on which browser. postMessage for some. VBScript for IE6 and IE7. And fragment identifiers for everyone else.
Jon: Does Gadgets use window.name?
Javier: (Checking) No
Jon: Howard says window.name cannot be made secure. My instincts are to look into the VBScript option before the window.name option.
Javier: Agreed.
States
Jon/Javier: no proposal yet
Javier: Once the APIs are stable, should be easy
Hub 1.0 APIs
Jon: This is about making sure that with the Hub 1.1 release it is possible to use the Hub 1.0 APIs separately and that they remain small like in Hub 1.0. There are 5-10 Enterprise products out there that are using Hub 1.0 today. We should allow them to upgrade to Hub 1.1, but not force them to use all of the mashup features if they don't need them. The mashup features are 10's of K of bytes, whereas the Hub 1.0 code is <3K after compaction.
Javier: Yehuda said we might want to use different Hub 1.0 instances with different Hub 1.1 mashup implementations.
Jon: Low priority. The shared code is very small. It's OK to require a particular core Hub with a particular mashup logic. The particular core Hub will still work for other applications so long as it implements the spec correctly.
RESOLUTION: Make sure it is possible to use older Hub 1.0 APIs on a separable basis for situations where people upgrade to Hub 1.1
Error Handling
Jon: This is from Howard comments at the face-to-face. What if client throws an error? Do we bubble it? I think not, and instead need to say in the spec that you shouldn't do that.
Javier: Our new APIs have error callbacks
Jon: If I remember correctly, we said in Hub 1.0 spec that subscribe callbacks should not throw errors. Whatever, we should say that in the Hub 1.1 spec.
Javier: We *could* catch errors
Jon: But we shouldn't. Maybe there is something in particular workflows where people are counting on errors in a certain manner.
Hub 1.1 takes objects?
Jon: Do the existing Hub 1.1 APIs allow objects?
Javier: No, originally strings only. Instead, we should support objects. The provider/container should take care of converting to JSON if it needs to do so for marshalling. Inline doesn't have to convert.
RESOLUTION: Up to provider/container to accept non-string payloads and marshall to JSON strings if necessary
