Interoperability Minutes 2009-05-11
From MemberWiki
URL: http://www.openajax.org/member/wiki/Interoperability_Minutes_2009-05-11
Attendees
- Matthias Hertel
- Jon Ferraiolo, IBM
- Javier Pedemonte, IBM
- Eduardo Abe, ILOG/IBM
- Howard Weingram, TIBCO
- Bertrand Le Roy, Microsoft
Minutes
Topic: Not all samples working
Matthias: Some of the samples are not working
Javier: I haven't updated them yet. Will fix them today.
Matthias: Path not present error
Topic: Closing spec
Howard: Has anyone done a sync between JSDoc in open source and wiki?
Javier: Yes, I did it. Should be up to date.
Topic: Event names moved to separate chapter
Howard: I'm OK with that change
Topic: Sample code in Managed Hub Overview chapter
Jon: I updated the sample application in the Managed Hub Overview chapter. You all said the sample code should run, so I got it running and it is now checked into our open source project. I borrowed code from Adam's implementation of OpenAjax Widgets, particularly the XHR trick to load the inline client's HTML snippet from a file.
Howard: I want to look at it.
Topic: JSDoc documentation conventions
RESOLUTION: Move elsewhere, such as to an appendix
Howard: Can I go over it offline?
Jon: Yes
Howard: I need to do a full pass. I'll try to do it by Wednesday.
Topic: Walk through colored notes in Managed Hub APIs chapter
(Approved removing all colored notes except what is listed here)
Howard: Cross-site scripting note: change MUST to SHOULD
RESOLUTION: Agreed
Javier: onComplete has an error. I'll remove the brackets on the params.
Jon: OK, yes that was dumb.
(discussion about unsubscribe warning about unsubscribe being immediate)
Howard: Not sure it belongs here. I'm OK with it here, but I think are other cautions like this.
Matthias: Maybe include a tag like "Caution". Keep it here for easy reading.
Howard: Remove the sentence that references the SMash paper. We use the tunnel for things beyond what that paper says.
Jon: OK
Topic: APIs with no text
Matthias: Some of the APIs have no text. Just the JSDoc snippet. Is that OK?
Jon: I think so. The main description is in the JSDoc snippet. Why repeat it?
Matthias: Looks like something is missing.
Jon: How about "The JSDoc comments above fully describe this API."?
Matthias: Fine
Topic: Best practices chapter
(Regarding top comment on preserving URL parameters)
Howard: This is about how we reserve oah* parameters. Need to move this out of Best Practices into another part of the spec. The key thing here is that redirection needs to preserve URL params.
Jon: Not sure where this should go
Javier: I thought it was more of an implementation detail
Howard: We have containers. Put it there.
Javier: Yes, that would be good.
Jon: I'll work on it.
Howard: Add reference to Hub 1.0 spec
Jon: OK, I'll do it
Howard: Drop the comments about HUB10 and HUB20. Confusing
Matthias: Agreed
Jon: OK, I'll do it
Jon: I removed the section on read/write sections in publisherData
Howard: Main thought is that when dealing with iframes, you have to pass by value
Bertand: I understand and agree. Fine with me. But do you have a pointer to the old discussion?
Jon: I'll send a pointer.
Jon: How about the handle on disconnect section?
Howard: Can remove the 2nd bullet. We hide the iframe instead of remove it. If reconnect happens quickly , then container is happy.
Jon: OK, I'll consolidate the first bullet into previous sentence.
Jon: How about reconnect proposal?
Howard: I will review the spec and recommend whether we have enough information on reconnect or will send in a writeup with a detailed proposal
Jon: My question about what API does the client invoke to change the URL?
Howard: Private protocol within a container.
Topic: Redirect logic in open source
Javier: I commented out some of the code to make redirect work. Our implementation doesn't fit the scenario described in the paper exactly, so I think we are OK, but Howard, can you please take a look?
Howard: OK
Howard: I don't think that the code that is commented out exposes an attack surface.
Javier: Two levels up is hardcoded in our case. Precludes an intermediary attack.
Howard: Need to verify origin, not URL
Javier: Yes
Topic: Test suite and source code
Javier: I think test suite is far along. With source code, only think is the redirect issue.
Topic: refOrName
Jon: I sent email with 3 proposals. (1) Don't support refOrName, (2) Only support what is necessary for Hub10 compatibility, (3) Support it across the board
Howard: I'm in favor of (2) for backwards compatibility. Can always add it to 2.1. No need to do it across the board at this time.
Javier: I'd rather not have inconsistency.
Howard: I don't want to break backwards compability for Unmanaged Hub.
Howard: Only need to do it for Unmanaged.
Jon: Then there is a 2a and a 2b. 2a only restored Unmanaged Hub. 2b also allows refOrName on subscribe() callback across the board. 2a is better. Only have to change the code in one spot.
RESOLUTION: Only support refOrName for UnmanagedHub.
Topic: Upcoming phone calls
RESOLUTION: Freeze spec by Monday May 18
RESOLUTION: Try to be ready for Release Review announcement on Tuesday May 26
