Interoperability Minutes 2009-03-16

From MemberWiki

Jump to: navigation, search

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

Contents

Attendees

  • Jon Ferraiolo, IBM
  • Javier Pedemonte, IBM
  • Eduardo Abe, IBM/ILOG
  • Howard Weingram, TIBCO

Original agenda

Minutes

Hub APIs chapter

Colored comment at very top of Hub API chapter

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comment in OpenAjax.hub.Hub.prototype.subscribe

Jon: I proposed changed from a more passive expression to a more active expression

Howard: Active working is OK

RESOLUTION: Update last paragraph to active voice

Colored comment in OpenAjax.hub.onData

Jon: There is a red comment about JSON serializable. What's that about?

Howard: Does the spec describe what the term means formally?

Javier: Do we really need a formal spec reference?

Jon: The introduction defines the term and references the JSON spec already. However, not a particular version of the JSON spec. Subject to change on a whim.

Howard: Ask Doug about how to achieve a referenceable spec

Jon: I'll send a note

Howard/Jon: We aren't looking for much formalism here. Hopefully some commitment to backwards compatibility and versioning.

ACTION: Jon to send note to Doug Crockford

Colored comment in OpenAjax.hub.Hub.prototype.unsubscribe

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comment in OpenAjax.hub.ManagedHub constructor

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.ManagedHub onSubscribe callback function

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.ManagedHub onPublish callback function

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.ManagedHub onUnsubscribe callback function

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.ManagedHub.prototype.subscribeForClient

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.IframeContainer constructor

Jon: What's IframeStyles? When was that added?

Javier: About a month ago

Howard: Launched our recent discussion about ids, styles, and classes

Jon: Have we figured it out yet?

Javier: Not yet. Still working towards a solution.

Howard: A few possibilities. (1) Could tell caller to create an IFRAME with whatever attributes are desired, (2) Caller could provide an array of attributes, (3) Pass in each attribute as a separate @param. Observe that we now get getIframe(), so you can change attributes after the fact.

Javier: My thinking is no styling by default

Howard: One problem is immediate sizing. May not buffer rendering. The mechanisms that are the most flexible is to create an IFRAME or create an array of attributes.

Jon/Javier: Afraid of passing in an IFRAME

Jon: How about pass an associative array, where each prop name is the attribute name? Property 'style' holds style attribute, property 'class' holds class attribute.

Howard: That's what I was thinking. Allows Manager Application to have veto power and to override. Matches notion that Container is the official owner of the IFRAME.

RESOLUTION: New param for associative array holding attributes to put on the Iframe

ACTION: Javier to fix code and spec

postMessage doesn't have tunnel yet

Howard: I noticed that the postMessage() implementation doesn't use tunnel for unload yet

Javier: Yes, working on that. Maybe today

(discussion about how the tunnel needs to be set up before a widget can be considered connected)

Howard: I agree with Javier's approach. Issue is that establishment of the tunnel might be slower than delivery of the postMessage. Don't want IFRAME to be visible before unload detector has been set up

Javier: Going back to the question of hiding and showing the IFRAME. My main concern is that we need to make it more general. Allow the Manager Application to override the behavior.

Howard: That why we have onConnect. Allows overlaying of a DIV that says "Loading..."

Jon: How about the 4 new paragraphs?

Howard: Not necessarily perfect, but we needed something. Rough swag. Painful to write.

Javier: They look fine

Jon: I'll look at the wording

Javier: Maybe a better term than tunnel?

Timeouts

Howard: I've concluded they are required

Javier: Good

Colored comments in OpenAjax.hub.IframeContainer.getIframe

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.InlineContainer constructor

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Colored comments in OpenAjax.hub.HubClient.prototype.connect

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Best Practices chapter

wiki page name

ACTION: Jon to rename wiki page from "Publish Subscribe Best Practices" to "Best Practices"

events

Jon/Howard: Existing text from Hub 1.0 spec is fine

undetermined order, async events

Howard: Let's break into 2 sections, one on async events and the other on event ordering. We want to say if Client A publishes event 1 then event 2, Client B should receive event 1 before event 2. But no particular guaranteed order if two clients are publishing the same event.

Howard: I'll take a stab at fixing this.

callback should not throw exceptions

Howard: Which one: MUST NOT throw exceptions but Hub will capture anyway, or SHOULD NOT throw exceptions but Hub will capture anyway

Javier: MUST

RESOLUTION: Change to MUST

Howard: Remove stuff on not relying on exceptions since you must not use them

subscriber callback function guidelines

Jon: Why are we suggesting that Client Applications might call Container and Manager functions?

Howard: Best Practice is don't do that. But you theoretically could if you are inline.

RESOLUTION: Change text to say: While you could do ..., you should not.

Howard: Maybe this needs to go in a section on isolation of clients.

Jon/Howard: Need to rewrite into a single coherent section.

Jon: There is a note about needing a diagram.

Howard: If the Best Practice is complete isolation, then we don't need a diagram.

publisher/subscriber independence

Howard: Maybe we can blow away the previous section by pulling content from it into this section. Second part of the independence section is the core information.

read/write sections

Howard: I would say that it is Best Practice to not have read/write areas in data

Jon: We are just saying what is a best practice. Not saying you can't do read/write.

Howard: I propose that we eliminate the read/write best practices

Jon: Any objections?

(none)

RESOLUTION: Replace with something that says not to have read/write sections

Jon: OK, between the two of us, let's clean up these two sections

frame phishing, load timeout, connect immediately

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Handling onDisconnect

Jon: What about the note from Howard about other cases?

Howard: That's the reconnect behavior

RESOLUTION: Can remove red-colored note and 2nd bullet

IframeContainer not change the src url

Howard: Let me explain the scenario. Need to reconnect with a new URL. With JSR168 portlets, pretty much the only way to get info is via URL params. Reconnect to URL with same domain as original frame. I will come back in email with more detail.

Jon: But an OpenID server might be different, so we talked about providing a list of allowed domains

Howard: I'll include that in the write-up.

"Polite" vs "abrupt" removal of Containers

RESOLUTION: Topic has been addressed, reviewed, approved - can remove red-colored comment

Reconnect not allowed

Jon: Remove this?

Howard: Yes, blow it away

Jon: I'll do that

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