From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-12-08

Attendees

Matthias Hertel
Jon Ferraiolo, IBM
Ted Thibodeau, OpenLink
Rama Gurram, SAP
Javier Pedemonte, IBM
Kin Blas, Adobe

Minutes

Agenda is to review emails in past 10 days, particularly:

subscriberData

Jon: Howard, Javier and I lean towards adding it back in.

Javier: Howard gave some good reasons to keep it.

Jon: Any objections to putting it back in?

Matthias: We can keep it.

RESOLUTION: Include subscriberData

unsubscribe onDone

Jon: Decided we needed an onDone callback

Javier: Yes, an async callback is useful in some situations. Howard said it was a mistake to not have it.

Jon: Any other comments?

RESOLUTION: Include subscriberData Correction: Should read "Include onComplete"

getParameters

Jon: I wasn't sure about this one. Need to talk to Howard. Is this just a manager-side feature or is there use on the client also?

Javier: I wasn't sure either. I'll check emails. Maybe can be moved up from base to Managed Hub.

(will keep this open until we can talk to Howard)

sendEvent subscriptionId

Jon: Lack of subscriptionId an oversight?

Javier: Yes, correct.

RESOLUTION: Add subscriptionId

subscribe/publish callbacks

Jon: This is the most involved item, with multiple parts. First, Howard provided a breakdown between Managed Hub and Client Hub, between inline container and iframe container, etc. Everyone agreed with his breakdown.

Jon: Next item was whether we needed a NotAllowed.

Javier: I agree with adding it.

Jon: Any other comments?

RESOLUTION: Add NotAllowed

Jon: Next item is multiple versus single callbacks

Javier: I'm indifferent. I'm OK with Howard's proposal.

Matthias: I prefer a single error routine.

Javier: Main thing was security callbacks vs other error callbacks. Howard thought it was better to separate out the security concerns.

Matthias: You think a component might want to shut down if security problems? That's a good point.

RESOLUTION: Accept Howard's proposal for separate security callback

Jon: On a tangent issue, should client even find out about being denied permission? My feeling is yes. There is an argument that any information to malicious components is bad, but in this case, either we are sandboxing or we aren't. OK to tell components they were denied, but don't provide any details.

Javier: I'm fine with that.

Matthias: I agree. We have a rule that we when we have no connection, we always have to provide the same error.

JSDoc "*"

Jon: Yes, that's the right thing to do. I'll make sure our JSDoc to OAM converter does the right thing with "*".

Property naming conventions

Jon: Howard proposes camel case for public names and an initial underscore for implementation-specific private things. That matches our precedent from Hub 1.0. Therefore, I like his proposal.

Javier: Fine with me.

(no objections)

RESOLUTION: Accept Howard's proposal for property naming conventions

onPublish, onSubscribe as required

Jon: Howard wants to force manager developers to have to take at least a bit of action towards security by forcing them to provide these two callbacks, even if they just return true. I agree with his reasoning.

Javier: Yes, but I'm always skeptical about things that require dummy functions. But his reasoning is fine with me.

RESOLUTION: Accept Howard's proposal for requiring onPublish, onSubscribe

OpenAjax.js inside of OpenAjax-mashup.js

Jon: It looks like Howard has included logic and APIs for Hub 1.0 within OpenAjax-mashup.js.

Javier: I haven't looked at the most recent check-ins.

Jon: I'm OK with that as a short-term developer expediency, but before we go final, we need to find a way to have a small footprint version that people can use when they only need Hub 1.0 functionality. Maybe separate back out the OpenAjax.js file or duplicate the logic where a developer can either use OpenAjax.js or OpenAjax-mashup.js.

Javier: Agreed

Matthias: Yes, what you said is right

RESOLUTION: We need to find a way to allow developers to use Hub 1.0 functionality with small footprint and not force everyone to include OpenAjax-mashup.js

OpenAjax.hub.Hub

Jon: This is confusing. Why hub.hub? Why is one lowercase and the other uppercase? Can we find a different name for the 3rd part?

Javier: I believe no one implements OpenAjax.hub.Hub. It's just interfaces that are implemented by ManagedHub and ClientHub. We could call it HubInterface or HubIFace.

Jon: Therefore, if not implemented anywhere, OK to use a longer name, such as HubInterface.

Jon: Not a critical issue at all. Whatever we decide isn't that important one way or the other.

Moving Hub 1.1 branch to mainline, updating Hub 1.1 spec

Jon: Should we move the Hub 1.1 branch with the new APIs to mainline?

Javier: Not yet. Still need to work on smash provider. Let's talk about it next week.

Jon: Change the Hub 1.1 spec now? I'm interested in updating the Hub 1.1 spec ASAP to reflect our most current thinking. What's there now is out of date.

Javier: Best to wait one more week.

Jon: OK.

Next phone call

Jon: Let's have a phone call next week to go over any remaining issues and review what we learn from implementing. Might be a short phone call, but let's have one nonetheless.

Interoperability Minutes 2008-12-08