Interoperability Minutes 2007-08-08
From MemberWiki
Full minutes: /member/wiki/Interoperability_Minutes_2007-08-08
Contents |
OpenAjax Alliance Interoperability Committee meeting minutes 2007-08-08
Attendees
- Gideon Lee <glee(at)openspot.com>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Greg Murray <greg.murray(at)sun.com>
- Bruce Johnson <bruce(at)google.com>
- Kevin Hakman <khakman(at)tibco.com>
- Krishna Sankar <ksankar(at)cisco.com>
- Ted Thibodeau <tthibodeau(at)openlinksw.com>
- Adam Peller <apeller(at)us.ibm.com>
- Coach Wei <coach(at)nexaweb.com>
Original Agenda
- Agenda
- OpenAjax Hub 1.1
- Report from Communications Hub face-to-face meeting and hallway discussions
- Highlights of recent discussion
- Hub 1.1 would be backwards compatible with Hub 1.0
- (???) Merge Communications Hub Task Force into Interop WG (???)
- Extend pub/sub engine to support cross-frame and client-server (particularly Comet)
- Attempts to address secure mashups by leveraging IFRAMEs for sandboxing
- Initial focus would be getting prototypes working in open source. Spec comes later.
- (???) Start open source work soon (???)
- OpenAjax Registry
- Jon has attempted to consolidate previous discussion on the Registry wiki page
- URLs:
- OpenAjax Hub 1.1
Minutes
Topic: OpenAjax Hub 1.1
(Jon repeats sub-bullets shown in agenda above. In particular, extend pub/sub to support frame-to-frame communications within secure mashups and client-server communications to address Comet push)
Jon: Comments or questions?
Greg: OK, applies to mashups. Also to portals?
Jon: Yes, could apply to portals. I expect there will be a blurry continuum between next-gen portals and mashups.
Ted: Could think of a portal as a mature mashup
Jon: My spin in the other direction is that a next-gen portal is a mashup app where portals embrace the Web2.0 contact of the user in charge
Jon: Comments or questions on Hub 1.1?
Bruce: Why was Comm Hub TF separate to begin with?
Jon: At OpenAjax Alliance, we create task forces when we have new areas for exploration. Communications was a new area. The role of a TF is to get interested parties together and ultimately make a recommendation to the alliance about how to move forward. Typically, (1) Establish a new WG, (2) Pursue new activities within an existing WG, (3) Do nothing. With Comm Hub, there is talk about going for option (2) and add client-server communications to existing Hub.
Bruce: What is the overlap between the Comm Hub TF and Interop WG?
Jon: (lists people) Just about everyone who is active in Comm Hub TF is also in Interop WG
Kevin: Joe Walker might be more active in Comm Hub that Interop
Jon: Comments about leading with open source efforts and letting APIs and specs come later?
Krishna: Matches IEEE approach. Makes sense.
Topic: OpenAjax Registry
(Jon explains how he codified previous proposals that were discussed in prior phone calls and recent email discussions onto the OpenAjax Registry wiki page.)
Jon: Let's walk through the changes over what we discussed previously.
Jon: Bertrand suggested that instead of just a JSON structure we should make the official Registry file into executable JavaScript. Due to this change and some thoughts I had, there are minor changes to how the registry is defined and located. Now, the proposal is the Registry is a JavaScript file that includes an assignment statement to fill the OpenAjax.Registry object with an associative array, one entry per toolkit. This associative array idea isn't new, we discussed it before.
Jon: Also, given a JavaScript file, it seemed natural to have a corresponding HTML file that would render the data structures within the JavaScript file.
Jon: Within the entry for each toolkit, I added two fields. 'version' indicates which version of the toolkit matches the registry entry. 'specificationURI' is for when the toolkit registers extensions to core JavaScript or DOM objects. In that case, latest proposals would require a specification for the extensions.
Jon: What do people think?
Krishna: Are there issues with name collisions?
Jon: There definitely are issues. When toolkits simply add a small number of global objects and attach everything to these globals, then collisions are minimized. But when toolkits change core JavaScript objects, then there are cases where leading toolkits cannot be used with each other. But I don't remember the particular cases.
Krishna: A new extension might break a currently running application.
Bruce: That would be bad.
Kevin/Jon: json.js redefines for/in loop and can break existing logic.
Krishna: How about namespacing?
Jon: In the case of new globals, our registry is a poor man's version of namespacing.
Kevin: What is expected size of the registry?
Jon: Wild guess. In a couple of years, maybe 50 toolkits have entries. Most toolkits have a couple of globals. A small number have a longer list due to extensions to core JavaScript and DOM.
Kevin: Need to think ahead to mashups. Facebook, MS Popfly, and iGoogle will promote collisions as the mashup app and the tens of thousands of mashup components define their own globals. Suppose multiple components use the global name "map". Metaphor is that toolkits are atoms and mashup components (gadgets) are molecules.
Jon: Excellent points
Kevin: Don't need to address now, but need to keep in mind as we work on issues
Jon: Agreed
Jon: For topic names in Hub 1.0, we have a SHOULD for reverse domain approach to topic names to avoid collisions. Implication is that we could recommend that organizations use "org.mycompany." for their globals. But would we want to promote this?
Kevin: Sure. Make logical sense.
Krishna: Is the registry descriptive or prescriptive?
Jon: If I understand your question, I would say descriptive, although because the Registry will be expressed in executable JavaScript, it could be used in automation scenarios.
Jon: Back to JavaScript and DOM extensions. Any comments or questions? Please say something even if you think this is a good approach.
Kevin/Bruce: Reasonable
Kevin: Well-positioned and framed well
Bruce: Anyone who would be strongly offended wouldn't have the right spirit about interoperability
Bruce: How about the question about Bertrand's suggestion on HTMLElement? Are there alternate proposals?
Jon: Not yet. I don't think anyone has given this issue much thought. My instincts are that HTMLElement can't be the right approach. There might be other presentational languages such as SVG and there might be scenarios where you extend tables in HTML but not other elements such as DIV and P. We need an issues page and I'll put this topic as an issue.
Jon: Let's go to the Registry Candidates page. Sorry about this page. I noticed a typo at the very top which will be confusing. The basis notion is that this page is an index to other wiki pages. Just two sections here. First section gives instructions for changing. Second section is the index. There are separate wiki pages for each toolkit that describes their proposed registry entries and the current status of discussions. How do people feel about this approach.
Bruce: Seems pragmatic. Good idea.
Krishna: Who will maintain the various pages? The toolkit vendors?
Jon: OpenAjax Alliance as a whole. We'll assume we can count on honesty and good behavior.
Krishna: Do we require backwards compatibility?
Jon: We have talked about this and has been in the Hub spec to some level. Basically, I am promoting an approach where to be OpenAjax Conformant a toolkit has to have reasonable behavior regarding backwards compatibility. Generally, need to have it, but if not, then there must be a good reason, suitable documentation about the change, and preferably new version catches the old construct and puts up some sort of error message.
Krishna: Looks like we need multiple versions for a toolkit in registry so people can find the older version.
Jon: Yes, looks like that will be the case
Jon: Further comments or questions?
(none)
Jon: Actually I had one. We need to have an explicit set of criteria for deciding what globals we will approve. I will write up a proposal for the criteria.
Jon: Next step is running through globals for some toolkits.
Krishna: Do we have a harness?
Jon: The registry wiki page has a section on tools, which includes things in the area of harness, such as tool to verify that a new registry entry doesn't collide with a previous entry. We will need some of these tools early in the registry process.
Jon: Next steps: Get a initial draft of criteria. Start to review particular toolkit globals. Have some tools working. I'm not sure I can have enough stuff ready in two weeks, so there is a chance we might skip the next meeting, but for now assume it is on.
