From MemberWiki

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

Contents 1 OpenAjax Alliance Interoperability Committee meeting minutes 2007-03-07 2 Attendees 3 Original Agenda 4 Minutes 4.1 Topic: Face to Face Meeting 4.2 Topic: Various small changes to the Spec for the Hub and Open Source Project 4.3 Topic: Higher Level Topics (Jon and Alex) 4.4 Topic: James' performance improvements 4.5 Topic: John Resig's comments

OpenAjax Alliance Interoperability Committee meeting minutes 2007-03-07

Attendees

• Adam Peller <apeller(at)us.ibm.com>
• Alex Russell <alex(at)dojotoolkit.org>
• 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>
• Jon Ferraiolo <jferrai(at)us.ibm.com>
• Kevin Hakman <khakman(at)tibco.com>
• Shailesh Hingole <shingole(at)gce2000.com>
• Ted Thibodeau <tthibodeau(at)openlinksw.com>

Original Agenda

• Agenda
  • F2F meeting - Register or starve
    • (Actually, there are vending machines down the hall)
    • /member/wiki/2007_March_Members_Meeting
    • /member/wiki/2007_March_Members_Meeting_Agenda
    • /member/wiki/2007_March_Members_Meeting_Registration
  • AJAXWorld press release and placard around InteropFest
    • If you want to participate in the press release, need to get going
  • Recent changes to spec and open source
    • Late binding of refOrName/scope finally implemented
    • Got rid of modules Libraries and Globals (not part of core)
    • Added module Collision
    • checkForCollisions() now returns an array that lists the collisions that were found
  • Small Hub change to discuss
    • OpenAjaxConfig.bootstrapFile becomes OpenAjaxConfig.modDir (directory where JavaScript for other Hub modules can be found)
  • James' performance investigations and proposed source code changes
  • Discussion of other issues raised by John Resig (http://ejohn.org/blog/thoughts-on-openajax/)
    • 38.3kB uncompressed and about 7kB
    • Waiting for window.load event not always the best thing
    • Use of window.attachEvent() instead of addEventListener
    • Markup scanner defines its own markup selector APIs instead of using standards
    • His recommendations:
      1. Use DOM event listeners in your code.
      2. Use a DOM Ready implementation to avoid using window.onload
      3. Use simple DOM queries to locate your pieces of markup (getElementsByTagName).
      4. Never overwrite any global variables.
      5. Keep your code confined to a single, global, namespace.

Minutes

Topic: Face to Face Meeting

• IBM Hosting and providing food
  • Would appreciate an accurate list as possible to provide accurate count.
  • If not sure you will attend, put your name on the registration page with comments for when or if you think you will be attending.
• Activities at AJAX World
  • Marketing committee is working on a small sign to be used by companies that pass the tests.
    • Sign says:
    • Had a lot of discussions with companies about they like and don't like to display in their booths.
    • 6 or 7 toolkits that are known to be ready by the show.
  • In addtion to signage and faq there is a press release.
    • Focus is membership growth (continue to get new members and Interop-Fest.
    • If your organization is participating successfully in the interop-fest, this is your chance to get your name in on the press release.
    • Jon can send folks info about this.

Topic: Various small changes to the Spec for the Hub and Open Source Project

• Code Changes:
  • We never implemented a late binding feature. Jon checked this in yesterday.
  • Libraries and Globals are now gone and are part of the Core in the bootstrap file.
  • Separated out the collision check into its own module.
  • Routine that checks for collisions now returns an array of all the collisions. It used to throw an error.
  • Bootstrap Configuration changed to reflect his

Topic: Higher Level Topics (Jon and Alex)

• Markup scanner (John Rezic, Jesse from Tibco) complaints about how it works.
  • Jon: Don't know of anybody using the markup scanner in their toolkits yet.
  • With all the uncertainty and the fact that the markup is half the size of the toolkit, thinking we will postpone it out of the original release. Since no one is using it maybe we need t ochange our approach, or may have perf problems.
  • Jon: Lets talk about our ideas at the face to face.
  • Kevin: Thinks its a good idea to delay it. It becomes important in a portal environment when integrating different libraries from different vendors. Given that no one is embracing it, and there is no demand, deferring makes sense.
  • Adam: Doesn't disagree. Is a resource constrained environment. We can't afford to look at it now.
  • Ted: Mostly agrees. Reason no demand is because its mostly a page developer need for mashups. Most folks are building toolkits that are used solo on a page. Worried if we push it off too far it becomes becomes a reason folks won't adopt oaa.
  • Alex: Unity in thinking regarding the way to search a page? A lot of toolkits have started implementing XPath or CSS selector approach. Very few folks use a markup scanner as we've spec'd it.
  • Jon: Agrees with Alex. The community is gravitating in that direction. W3C is making progress on an API with a long name. GetElementsBySelector() ... it would mean the browsers as they implement this feature, would provide a list of elements that matched the selector. It would be fast since its native support. This is a different approach than the markup scanner.
  • Alex: Open AJAX code to get functionality. Dojo just released a page searching engine for Dojo explicitly staying out of the way of the selector approach just in case the browsers support it.
  • Jon: Yahoo uses a list of IDs which is a subset of w3c.
  • Alex: Portal environment is interesting. Are portlets nested in portlets.
  • Kevin: 6 portlets on an HTML page. Using 2 or 3 toolkits. Concievable there would be a toolkit in a toolkit. Like Dojo in GDI.
  • Alex: Would each one be searching the entire page?
  • Kevin: Possible?
  • Concerns about including multiple versions of the same toolkit.
  • Kevin: Certainly possible.
  • Jon: Orthoganal to the page scanning problem. Prototype needs to deal with making sure things don't squash each other.
  • Jon: Portlets should be scanning subtrees.
  • Alex: Is there some way we can recommend that way.
  • Jon: We should think about best practices we can recommend. And perhaps get out of the business of providing code. No test suite required. :-)
  • Jon: Ted how do you feel about this?
  • Ted: Going along with it.
  • Jon: Will talk in 2 weeks about postponing the markup scanner.
• John Resig pointed out issue of doing too much with window.load event.
  • 2 problems with document load:
    • Tibco found that it occurs too soon. Tibco doesn't do its processing till a bit later.
    • John found that there's a preload event. Doc is fully parsed but images and other resources may still be loading.
  • Each toolkit has a different definition of this preload event.
  • Other interesting events that we may consider.
  • Alex and Jon feel that in order to simplify things in the code and make download and api smaller, we might want to postpone the load/onload module we have right now and replace with/integrate into the features it supports using the publish/subscribe bus. We could publish the event that the OA registered an event handler on the window/body and we publish that our event handler has been called (body onload has been invoked). Other folks can listen to us for that event without having a separate event without having an load/unload module.
  • Alex: Confusion different toolkits have different semantics all related to browsers facilities. WOuld be a good thing for us to try and do that as opposed to define an onload semantic that might not work for some folks.
  • Jon: Alex also suggested that toolkits publish their preload notions/important loading events. We could encourage them to invoke the topic bus. Yahoo's notion of preload has happened.
  • Alex: Toolkit onload event is something they should publish. Toolkits should not blow away the onload handler. They should safely add to it if they are going to add one.
  • Jon: Toolkits and Applications.
  • Alex: Applications can use the events we are throwing across the hub and not have to worry about onload.
  • Alex: We may be lynched by the Tibco guys about the test suite.
  • Jon: They were afraid they weren't passing because they didn't use the load/onload handler. By eliminating it there's no question.
  • Kevin: This simplifies and solves these issues.
• (Jon + Alex) Postponing the register globals feature.
  • Doesn't seem like anyone is taking advantage to it. We don't have a big solution.
  • If no one is using it then why not postpone it and make it right.
  • Register globals, give a prefix and supply an array of strings. If no one is using it and we're not sure its right, then why not postpone it.
  • Kevin: What's left and what's the value of what's left to the community.
  • Jon: Register libraries and the event bus.
  • Kevin: and a collection of best practices.
  • Alex: A growing list of oaa events, like noting onload or begin/end of D&D.
  • Kevin: Those things might be worthwhile to hit for the first release.
  • Alex: Agreed
  • Jon: What do you think about this collection having critical mass?
  • Kevin: Value is when you use things that conform you're assured you won't be clobbering things, toolkits easily communicate, and a lot more info (mixing and matching). Expectation is for the toolkits to embed the hub. Be a semi-permanent part of the toolkit as it ships. In tibco's case there's a checkbox to include it or not.
  • Alex: they get to drop a bunch of code out of their toolkit for onload handling. And that's pretty much it for now and a marketing gold star for being compliant.
  • Jon: They get an event bus if they don't have one already.
  • Alex: Some don't have any.
  • Kevin: Excellent point.
  • Craig: Social engineering part to think about. We've always said interop is important. Globals and namespaced variables and polution are important. If we defer it now that in order to upgrade your going to have to do this additional stuff. We shouldn't gratuitously ask them to add them. We should do it now rather than later.
  • Jon: Benefit for consolidation for this release. We can have the hub fit in 1-2K compressed. If we remove the load stuff we end up with something small enough that toolkit folks might just throw it in and keep life simpler for their developers.
  • Kin: We should at least have some best practice suggestions around this.
  • Alex: Agreed
  • It's an authoring time thing, not a run time thing but it gets sent down to all users anyways.
  • Jon: Bigger picture what is the go to market strategy in terms of features. What do we want to do with future versions.
  • Communications Hub task force won't get into 1.0. How will this relate to future versions.

Topic: James' performance improvements

• Jon: James Margaris is not on the call so we shouldn't talk about his perf findings.

Topic: John Resig's comments

• Jon: Bat around the comments from John Resig
  • Current Hub is 38K (uncompressed) / 7K (compressed). If we did these changes we would be 1-2K compressed. Small is important.
  • Windows load event is not always the best thing.
  • Window.attachEvent ... do modern browsers support this?
  • IE does not have a solution.
  • Markup scanner with its own selector apis
  • John Resig's Recomendations:
    • Use dom listeners in your code.
      • Alex: Naive reccomendation.
      • Jon: If DOM3 was implemented properly
      • Alex: If DOM2 were implemented properly we wouldn't be here
    • Never overwrite global variables.
      • Kevin: Global variables or global objects?
      • Jon: The way I interpreted was that if you have a toolkit, before you add a global you should see if it already exists.
      • Jon: JSON.js Prototype, are these things ok to do? Do we think their bad?
    • Keep code confined to a single global name space.
  • Jon: I communicated privately with John. He works for Mozilla. He might attend the face 2 face event on behalf of Mozilla. I suggested that the best approach be that he attempt to join as an individual. Sign the agreement as an individual and represent JQuery and participate actively. 2nd best is if he could join representing Mozilla, and 3rd best that we communicate through back channels and blogs.