[OpenAjaxInterop] Minutes 2008-11-24

[Jon Ferraiolo]

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




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:
      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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/interop/attachments/20081124/d86f5f1d/attachment.html