Interoperability Minutes 2009-03-30

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-03-30

Contents

Attendees

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

Original Agenda

  • Agenda
    • Debugging cross-frame Hub applications
      • Howard's original suggestions [1]
        1. If the JavaScript "debugger" keyword is present in one code path in the HubClient constructor and one code path in the tunnel setup, then if we use parameters to control whether this path is executed, we can effectively enable and disable breakpoints early in the life of each window. The early breakpoints then allow the developer to add additional breakpoints manually.
        2. To allow the Container to control whether the HubClient and tunnel halt early in their setup processes, we could add an optional iframe URL parameter oahd=1 to the initial iframe URL (can subsequently be dropped?). The IframeHubClient and tunnel code could look for this. We could then add an optional params.IframeContainer.debugLoad parameter to the IframeContainer constructor. When present, this would tell the Container to set the oahd URL parameter, enabling debugger halts in the client iframe and tunnel iframe.
        3. Other brainstorming ideas (statistics, detailed status queries, external tooling, information resources, ...)
      • Howard's response to Adam [2]
        1. Include a log statement in the catch block providing the callback context and e.message.
        2. Include the debug keyword in the catch block, at least in uncompressed builds. This could be controlled by the same param value (except for callbacks invoked by ManagedHub; we could make ManagedHub take a param, I suppose).
        3. Let exceptions propagate up, though this risks interfering with the proper functioning of the hub, e.g. an exception in the wrong place might abort steps that are security-critical.
      • Howard (later) [3]
        • I think we should certainly do #1 (logging).
        • I think it would be a good idea to have #2 (debugger statement) in the non-compressed case, which should generally only be used by developers anyway. The compressed production case should have the debugger statement stripped out. We could make this conditional on a debug mode (e.g. params.Container.debug) or not. We DO include language in the Hub spec that says that callbacks are not supposed to throw exceptions and are supposed to catch and manage these exceptions themselves, so maybe we don't need to make these violate the spec, so maybe we don't need to turn them off... .
    • Container/HubClient getPartnerOrigin [4]
    • IE8/Opera postMessage is synchronous [5]
    • Version string in iframe protocol [6]
      • Howard provides details [7]
    • Message leakage [8]
    • FIM and the back button [9]
    • Start load timeout when client disconnects [10]
    • Test suite status update
    • Review recent spec editorial updates and discuss open issues (red-colored comments)

Minutes

Debugging cross-frame Hub applications

Javier: I agree with Howard regarding #1 logging and #2 debugging

Howard: Do we remove debugging from the release version?

Javier: Definitely keep logging. I guess we could leave debugging.

Howard: I'm changing. Debugger in release build is unreadable due to compaction. Could include in all versions, but have null function in release

Javier/Matthias: That's good

Howard: Any other troubleshooting objectives?

Javier: We have logging in the code. Good logging goes a long ways

Howard: I generally like what's in there now, but I want to look at it again

Matthias: Debugging is hard due to timing issues. Logging is fine.

Jon: Dojo has debug statements but a config flag to turn it on.

Howard: Yeah, opt-in. But I'm not all that hot on a new flag.

RESOLUTION: Optional opt-in params for debugging in constructors for ManagedHub, Container and HubClient. Do not pass debug flag as URL parameter.

RESOLUTION: Don't need anything new for logging. We already have an opt-in mechanism.

getPartnerOrigin

Jon: Any objections?

Matthias: I don't see the use case

Howard: Widget might want to check on who the container is. If provided at Hub level it's trivial to do. If forced to do private things, you have to reimplement many things that are in the Hub.

Matthias: What is the origin?

Howard/Jon: protocol and domain

Javier: postMessage also uses port

Howard: port has some issues. IE doesn't distinguish different ports from the same domain. Also, some browsers wrap around.

Matthias: I'm OK with this.

RESOLUTION: getPartnerOrigin is approved

IE8/Opera synchronous postMessage()

Howard: Javier had a great suggestion, which was a zero second timer

Javier/Howard: Good to make everything consistent using async

Javier: You suggested a way to test for sync

Howard: Yes, use postMessage to send a message to itself. Can tell if synchronous if message received before publish completes.

Javier: That might not be bad. Could do this with the first instance of a container. I'll have to test across all browsers.

Iframe protocol version, message leakage and FIM back button

Matthias: Would we change the protocol within a Hub 2.0 implementation? Shouldn't we up the version number?

Howard: But protocol isn't defined by the standard. Spec says a Container and HubClient define their own private messaging protocols.

Howard: Maybe in 2.1 we can define a standard protocol, but not for 2.0.

Howard: Reference implementation may need to evolve, which might lead to changes in the protocol it uses internally. What we should do is put a version# on the protocol but not the implementation

Matthias: Leave it out until we have a spec?

Javier: I'm thinking version# on the implementation, not the protocol. Suppose a Container and a HubClient that match, but rev'd separately. An updated container might be able to deal with an older HubClient via backwards compatibility

Howard: Proposal is for one version string for the protocol, such as openajax.fim.2.0 and openajax.pm.2.0, or shorter oafim2.0 and oapm2.0. Only in the implementation, not in the spec

Matthias: OK

Javier: Fine with me

RESOLUTION: Approve Howard's proposal on version# for protocol used by our implementation

Howard: With FIM, can hit the back button and it may attempt to restore the current state

Javier: Maybe best practice is to override the back button

Howard: I'll look at this and see if it works. Then don't have to have connection ids

Matthias: OK

ACTION: Howard to look into overriding back button

Start load timeout when client disconnects

Howard: Usually, disconnect when you are navigating to a new site. Don't want to leave an infinite amount of time for reconnect. If it doesn't, maybe allowing a brute force attack on the token

Javier: I agree with Howard, but I was wondering if we are missing a use case where someone wants to reconnect after awhile

Javier/Howard: Can't think of a scenario

Javier/Jon: Better safe than sorry for now. Can extend later if necessary

RESOLUTION: Start load timeout when client disconnects

Test suite

Jon/Javier: Code checked in for generic creation of containers of different types

Javier: Needs to be restructured. Checked in so people could review it. Allows tests to be run multiple times across different containers.

Howard: Yes, as generic as possible.

Javier: I'll keep fleshing it out

Howard/Jon: Need to work out high-level test suite organization now. Be sure to look at the wiki page I created

Javier: OK

Howard: Besides testing the reference implementation, also might make it easy for developers of 3rd party containers

Retrieved from "http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-03-30"
Personal tools