From MemberWiki

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-11-25

Attendees

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

Minutes

(The point of this special one-off phone call is to get Howard's feedback on the proposed Hub 1.1 API changes: http://www.openajax.org/member/wiki/Hub_1.1_Proposal_Nov_2008. Howard had a civic duty that conflicted with the previous day's phone call)

Howard: I have lots of feedback. I'll give some of it verbally here, but I'll also update the wiki page that has the proposed changes. Some feedback is big, some minor.

Howard: No need for createManagedHub(). Just make it a constructor. Doesn't fail in any particular way.

Javier: Yes. I ended up doing it that way in my prototype code.

Howard: Constructor arguments: I would prefer a single object with multiple properties instead of distinct arguments. I want to add a securityalerthandler

Jon: I prefer that also

Howard: Also, nitpicky, I have various name proposals. For example, rename callback parameters to promote consistency.

Javier: Yes. I was thinking of renaming things

(Howard/Javier talk about a renaming approach. Not minuted. Presumably, will appear on proposal wiki page)

Howard: I would get rid of getConnectionHandle(). What I am thinking is that there is a hub interface, not a class. Implemented by both ManagedHub and ClientHub. Has publish(), subscribe() and isConnected().

Javier: I'm not totally following, but I'll look at your proposal

Howard: Mostly its about connHandle going away and replace by a hub object

Howard: I like the merging of clientHub and container. Simpler API will tend to result in less code.

Javier: I agree.

Howard: I like subscriptionID versus a subscription object

Javier: I haven't totally figure this out. Haven't gotten to this part of the implementation.

Howard: Whatever, either object or id, make sure it's data with no functions

Howard: I like how you brought together ManagedContainer and ClientHub

Howard: You create the container, you call connect to turn it on.

Javier: What if you are both a child and a parent of a managed hub?

Howard: Up to some piece of JS infrastructure to call connect, which would establish connection

(Howard adds: the JS infra mentioned here is JS that appears in the sandbox window in the iframe case. In a given container implementation, say a particular iframe+FIM impl, the container implementation will include the server-side component that renders the iframe. This component will ensure that the sandbox window will contain some JavaScript infrastructure that is automatically initialized when the iframe is loaded. It is this JS, rendered in the sandbox iframe by the server, that would instantiate the HubClient object.)

Jon: To repeat, call clientHub constructor, then call connect on that object?

Howard: Yes. Eliminates the complexity of the connHandle.

Howard: Disconnect? I'll add some comments.

(Howard adds: I was talking about state machine here. Events include connect called, connect succeeds, connect fails, disconnect called, disconnect completes)

Howard: Done callback is problematic. What if it calls disconnect? Lot of things to do to avoid problems in case you are way down the stack. Want to make sure things aren't deleted until stack is at a point where it is safe. No problem with onDone, just need to implement it in a particular way.

Howard: Also need a way to enumerate containers on managed hub. Run through with an API. Less risky than a bunch of extra code.

Howard: Callbacks triggered when client connects and disconnects. You want to do a clean shutdown of the client. Client app may be using resources that SHOULD to be cleaned up prior to blowing away the client, e.g. login sessions with servers, Comet channels, etc. Best practice for these to be shut down gracefully rather than having the client window closed, leaving the sessions hanging and the servers wasting resources. Much better if you allow the client to clean up neatly. So, I want my widget to be notified of a shutdown. The manager app should notify the client app via an app-level or gadget framework level event (no special treatment at the hub level for this event; it's just like any other publish as far as the hub knows), and when the client is done with the graceful shutdown it will simply disconnect. The manager app should be able to listen for client connect/disconnect for each container, as a low-level notification. (Howard: I edited these comments)

Howard: I really like the simplifications. Big improvement.

Howard: I want to move the subscription object to the hub level.

Javier: Hub 1.0 subscription tree, calls into container with subscription ID, and then container invokes the callback. Each managed hub has its own subscription list, but each container keeps track of callbacks

Howard: For cleanup, need to enumerate subscriptions. I'll have to come back to this.

(Howard: I am now thinking that this will be internal to the Container implementation)

Howard: Cleaning up subscriptions on the client side. Might be several libraries and using the Hub. Each library might have its own cleanups such as both Dojo and GI having their own subscription managers. The application is responsible for library cleanup.

Howard: I'll update the page with notes.

Javier: Good. I'm prototyping the changes now.

Howard: My big worry is the cleanup code, especially in the inline case.

Howard: Also, I'm using a queue for events.

Javier: To make sure one event finishes before another event fires.

Howard: Need to have a removeContainer in managed hub

(Howard: for security reasons, a manager application must be able to remove a container immediately and without warning to the contents of the container. This is different from the graceful shutdown as described above, in which the manager app notified the client via an event and the client then disconnected. When a security alert is fired by the hub, e.g. when a container load times out and frame phishing is suspected, the manager application may immediately remove the container and display an error message.)