Interoperability Minutes 2007-07-11

From MemberWiki

Jump to: navigation, search

Full minutes: /member/wiki/Interoperability_Minutes_2007-07-11

Contents

OpenAjax Alliance Interoperability Committee meeting minutes 2007-07-11

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>
  • Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
  • Howard Weingram <weingram(at)tibco.com>

Original Agenda

  • Agenda
    • Status report for finishing off OpenAjax Hub 1.0
      • All features implemented
      • Test suite: all features have tests
      • Spec: need to put content into References appendix and Example appendix, plus detailed editorial review. (Hope to enlist volunteers for the editorial review sometime soon.)
      • Still recruiting people to integrate the latest Hub with their toolkits
    • Open issues with the Hub
    • Second InteropFest in conjunction with AJAXWorld and our next F2F meeting
      • PROPOSAL: InteropFest 1.0 (to coincide with OpenAjax Hub 1.0 and OpenAjax Conformance 1.0)
      • PROPOSAL: One test case as follows
        • Requires at least two "Ajax toolkits" on same Web page (one of two can be a trivial toolkit that we supply with the test)
        • Success results are displayed within a fragment of HTML (versus previous test, which was a whole Web page)
          • Test case verifies that a library has registered itself and is using the pub/sub engine. (Continuous update of number of events published.)
    • OpenAjax Hub 1.1 Roadmap
    • OpenAjax Registry

Minutes

Jon: status: hub 1.0 the oss project has all features and all tests thanks to Bruce at Tibco. Two open issues. Two appendices in the specs need to be written. Final editorial nitpicking needs to be done. Volunteers needed for editorial review. Get Hub integrated with various toolkits. Conformance/interop test.

Bertrand: make sure the conformance tests can be downloaded separately from the rest of the project.

Jon: that's probably the case but I'll make sure. The same is true of the tests.

Next thing: open issues

Issue 16 (xmlns for each toolkit): voted OK by everyone. Closed as no objections. Jon will update.

Issue: list of characters in the event names: since JS specs include Unicode. What chars are disallowed? Period (separator), star (wildcard), slash and quote (single and double). Safari 2 has bugs in Unicode support. It has been suggested that you could provide an object that contains the separator char.

Greg: in jMaki we allow anything.

Howard: if we don't want to balkanize, we should have one separator and impose it, otherwise you get lots of dialects. It's better for simple things like this to just have a

standard.

Bertrand: single or double quotes or both?

Jon: I don't think it's a big issue.

Howard: I would recommend excluding all control characters (anything that you need a backslash to include in a string).

Jon: I think it works to allow anything but period because it's the token.

Howard: "..." should be handled gracefully; each token should be at least one character.

Jon: we have tests for empty names.

Bertrand: space is allowed? In the middle or on the sides?

Howard: people might be confused by spaces on edges of the name but it's probably ok.

Jon: Bruce, what about the list of chars that you recommend excluding?

Bruce: there's a bunch of Unicode chars that might be confusing so keep things as simple as possible. The fewer rules the better. Spaces at the beginning or end are

clearly confusing. Double quote has meaning but there are other symbols that we might think are fine but other cultures might not.

Jon: Let's use some "should" statements, like should not use quotes, should not use spaces on edges, etc. Not must, except for period and wildcard.

Bruce: event names should be easy to communicate, i.e. by e-mail, which pragmatically excludes some chars like newline. Is this just a recommendation?

Jon: we can go either way but I think it's enough to recommend.

Bruce: explicitly disallowing imposes more code in the runtime

Bertrand: would rather have more code in tests and less in runtime.

Jon: seems like the consensus is that we'll disallow only period and star and just recommend not using special characters. No objections.

We'll have another interop fest in September. Will be incredibly simple and basic. Just requires to show a demo of the toolkit registering itself and participating in the

pub/sub. Should be 10-30 minutes of work. Proposal should be ready in two weeks (next phone call). Sounds good to everyone.

Hub 1.1

1.0 was one frame where everyone could communicate. 1.1 will introduce cross-frame communication. Sandbox with secure communication channel. 1.0 is one frame, I'm suggesting that 1.1 goes cross-frame. Address comment that there's a problem with multiple Comet connections. Problem with browsers and server perf. Repurpose some of the ideas that were discussed in the interop committee. Finally, offline roadmap but that's probably more 1.2. Today's hub works without plug-ins. Bruce will give his proposal. Multiple windows could look at cookies on timers.

Gideon: do you mean cross-browser instances?

Jon: could be across browsers (between FF and IE) if it uses cookies.

Howard: Probably not possible without server intervention.

Jon: there are hosts and rooms which are the communication channels. A room is a common area to which different agents can subscribe and publish. There could be custom message rooms that are not managed by the hub but there's also the current in-frame room, the x-frame room. Within a room, things work with the current sub/pub specs as they exist today. You connect to a host, join a room and subscribe or publish events.

Greg: the api should sit above particular implementations such as cookie or location hash or whatever.

Jon: we want to define an abstract api that works with today's browsers but people could come later and implement that with something else.

Greg: we should take size limitations into account.

Howard: we should take into account that requests may fail (in particular when there's a server in the middle).

Jon: let's get to the OAA registry issues. I encourage people to review and send feedback. Final topic is Microsoft's registry propositions. How do we want to deal with globals, what approaches are acceptable? Bertrand sent the Microsoft list of globals. The data is on the wiki and is accessible from the registry page.

Global list: Sys is the global namespace. What do we do about extensions to built-in objects? Are they OK? Does a particular vendor own any extensions he comes up with?

Bertrand: evolution of APIs are the problem here.

Jon: evolutions should be back-compat.

Bertrand: it's actually not that simple.

Greg: any possibility we could exclude that completely?

Bertrand: that would be a big breaking change for each toolkit, you won't get consensus on that.

Jon: Prototype has most of its value in extensions. We should have a way to manage this, not forbid it.

Bruce: prefixing can be a solution.

Greg: this could be the big roadblock for interop.

Jon: seems like this extension issue is what we need to come up with a solution.

Bertrand: I'll try to dig out an old conversation we had that dealt with that.

Personal tools