Interoperability Minutes 2007-02-21

From MemberWiki

Jump to: navigation, search

Full minutes: /member/wiki/Interoperability_Minutes_2007-02-21

Contents

OpenAjax Alliance Interoperability Committee meeting minutes 2007-02-21

Attendees

  • Adam Peller <apeller(at)us.ibm.com>
  • Kin Blas <jblas(at)adobe.com>
  • Craig McClanahan <craig.mcclanahan(at)sun.com>
  • Gideon Lee <glee(at)openspot.com>
  • Ingo Muschenetz <ingo(at)aptana.com>
  • James Margaris <jmargaris(at)nexaweb.com>
  • Jesse Costello-Good <jcostell@tibco.com>
  • Jon Ferraiolo <jferrai(at)us.ibm.com>
  • Ken Tam <kentam(at)bea.com>
  • Kevin Hakman <khakman(at)tibco.com>
  • Rama Gurram <rama.gurram(at)sap.com>
  • Rick Evans <Rick.Evans(at)Sun.COM>
  • Shailesh Hingole <shingole(at)gce2000.com>
  • Ted Thibodeau <tthibodeau(at)openlinksw.com>
  • Greg Murray <greg.murray(at)sun.com>

Original Agenda

Minutes

Topic: Transition from Interoperability Committee to Interoperability Working Group

Jon reminded everyone to review the interoperability workgroup charter. We want to use the development process established to towards a charter.

Topic: F2F Meeting

Reminder that there is a face to face meeting four weeks from tomorrow. There are currently three pages on the wiki and the agenda are being developed on these pages. Everyone is reminded to put the names of the registration page so that meals and badges may be arranged. The web site doesn’t have the exact location but it is at the IBM building on Madison avenue. Everyone is advised to go over the agenda and to make suggestions.

Topic: Proposed changes to the Hub

Proposed changes to the hub: we are going through the code to clean up and to shrink down the code size. The small proposals are to merge two small js files (library and global) into the bootstrap file and to rename it to Open Ajax Core . Adam proposes to go further:

  • Get rid of the registration and un-registration functions because they are more or less convenience functions and they are only used by a small group of developers and only in initialization. Jon’s inclination to leave them as is rather than changing them into an array. A couple of others agreed that they liked the register*** functions over directly modifying the internal arrays. The query and the getters have been removed, though, because they are wasting space for download and are hardly used. Adam pointed out that size of the Hub will affect decisions by toolkit providers to include the Hub in their toolkits.

Jon agreed however with the goal and it should be to reduce the code size.

Agreement to leave the APIs as they now. We'll reconsider after dust settles. Options include keeping both register** and unregister** methods, keeping register** but getting rid of unregister**, or removing both.

Topic: Continuation of the architectural review of spec

To be OpenAjax conformance, a library must have a strategy to deal with versioning. The thrust of the hub design is to guarantee that different versions of the same library to co-exist on the same page. That guarantee should apply to the hub library itself.

  • The current strategy is to say that the hub should not load if any version is already loaded.
  • What if different libraries include different versions of the hub? Suppose you are using Dojo and Yahoo and they are using different versions of the hub. Dojo is loaded first and Yahoo next. Then the late comer Yahoo must not load the hub.
  • What if things fail? What if Yahoo needs the newer version of the hub but Dojo loaded an older version? The current design is that it will simply fail silently.
  • Another option is to trigger a throw. It could be either handled by the GUI or if not caught, shown to the console.
  • A couple of people suggested that it is up to the library to check to see if the right version of the Hub is available and deal with notifying the user.
  • Jon pointed out that when a particular toolkit is on top of the whole Web page, it makes sense that that toolkit deals with notifying the user. But in mashup and portal scenarios, it's this other bit of software that is on top. Probably need to evangelize to the mashup and portal providers the need to handle errors generated by the objects placed inside of them.
  • Jon suggested that error handling is a general topic that requires more thoughts. So a throw or silent failure might be what we can realistically decide upon for now.

List of modules. After merging the two small js files as discussed, there will be three runtime modules and the optional collision check module. We talked about a fifth for argument checking or debug.

  • The three runtime modules are: load/unload, publish/subscribe, and markup scanner.
  • Questions about a/synchronous loading of libraries. Is synchronous loading required of the browser? Insights: web browsers except for Safari provide methods for libraries to detect loaded event. There isn’t any workaround for the current Safari but it is a filed bug.
  • Adam/Jon proposed that the open source reference implementation can be customized by vendors to enhance the performance. This was in response to question from Jesse about being able to pull down multiple optional modules in a batch. Adam/Jon pointed out that the vendor could implement OpenAjax.require() to pull down multiple modules, not just one at a time.

Jon borrowed the scriptacular approach in dynamic module loading – it is referred to as the “load equal” approach. Jon wants comments on whether this is a necessary feature. The proposal is to take it out since it doesn't appear that anyone is using it so long as nobody objects. We can add it back in later if there is a demand for it.

  • OpenAjax Config bootstrapFile discussion. Not sure it still makes sense. It will be discussed next week. Jon will make proposal.
  • Configuration option discussion. No much else to discuss. We talked about the markup scanner previously. The bootstrap file option will be discussed next week.
  • Implementation Metadata: there are four values that you can check to see what version of the hub you got and the implementation you are using. The question is whether they are the right set of metadata. That should be reviewed.
Retrieved from "/member/wiki/Interoperability_Minutes_2007-02-21"