[OpenAjaxInterop] Minutes 2008-11-24

Howard Weingram weingram at tibco.com
Wed Nov 26 03:49:03 PST 2008


I¹ll post the changes tomorrow. I¹m sorry I was delayed today.
hw


On 11/24/08 12:53 PM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> We will have an informal follow-on phone call tomorrow 8am US-PT to check in
> with Howard. Same phone numbers and passcode.
> 
> Jon
> 
> 
> 
> Interoperability Minutes 2008-11-24
> 
> URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-11-13
> <http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-11-13>
> 
> 
> 
> 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
> <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:
>> * http://www.openajax.org/member/wiki/Hub_1.1_Proposal_Nov_2008
>> <http://www.openajax.org/member/wiki/Hub_1.1_Proposal_Nov_2008>
> 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
> 
> 
> 
> _______________________________________________
> interop mailing list
> interop at openajax.org
> http://openajax.org/mailman/listinfo/interop



--
Howard Weingram      650.846.1000
Principal Architect  TIBCO Software Inc.

TIBCO PageBus(TM) delivers ultra-lightweight
publish-subscribe messaging for mash-ups.
Learn more at http://www.pagebus.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081126/32f9aca9/attachment.html 


More information about the interop mailing list