Interoperability Minutes 2006-12-06
From MemberWiki
Full minutes: /member/wiki/Interoperability_Minutes_2006-12-06
Contents |
Attendees
- Alex Russell, Dojo Foundation
- Craig McClanahan, Sun
- David Boloker, IBM
- Gideon Lee, OpenSpot
- Guido Laures, SoftwareAG
- James Margaris, Nexaweb
- Jon Ferraiolo, IBM
- Kevin Hakman, TIBCO
- Rick Evans, Sun
- Ted Thibodeau, OpenLinkSW
Original Agenda
- Agenda
- Streamlining the process of developing the Hub
- Motivation: move faster and increase momentum in the industry
- Proposal: move JavaScript implementation and API discussion to email and IRC
- Candidate new activities for refocusing this meeting
- Interoperability Working Group Proposal and Charter
- Per our emerging Development Process
- Coordination requirements on the Proposal/Charter with the four Task Forces
- OpenAjax Hub Specification
- Ensure that the Specification is appropriate for submitting to the Membership and Steering Committee for review and then approval
- Skeleton draft: /member/wiki/OpenAjax_Hub_Specification
- Ensure that the Specification is appropriate for submitting to the Membership and Steering Committee for review and then approval
- OpenAjax Official Registry of Toolkits/Libraries and Associated Global Variables
- Modern-day version of the land rush?
- How about wiki page with "candidate" and "approved" global variable allocations (e.g., Global Object Registry, where we approved entries get added to open source implementation
- Members can add candidates by editing wiki page.
- Non-members have to use other means of communications (e.g., send email to public@openajax.org)
- Skeleton Best Practices wiki pages:
- Acid tests
- Motivation: give browser vendors (desktop and mobile) a tool for measuring their feature set and performance as needed by Ajax applications
- Need to coordinate with other organizations such as Web Standards Project
- Just mentioning this for now. There is a lot of research to do before we can have meaningful discussion.
- Interoperability Working Group Proposal and Charter
- Fewer phone calls?
- Primary reason for weekly phone calls was to expedite the Hub
- If we move Hub discussion to email and IRC, we won't have as much to discuss here, at least in the short-term
- Proposal: We reserve this time slot for use on an as-needed basis, and OK to cancel meetings if insufficient agenda, but default is every two weeks
- Streamlining the process of developing the Hub
Minutes
Topic: Streamlining activities within this committee
Jon: Spurred by comments from an Alliance member, proposal is to streamline our regular meetings of this committee, focus less on the detailed discussion of the Hub, and move our discussion to new issues. With regards to the Hub, we are far enough along to not need to have this committee meet weekly on that issue. Also, looking ahead, there are things we should be working on.
Jon: Coming Up: Ajax World in New York City soon (April), plus a face to face meeting. We should have more to show by then. In particular, we should be making progress on Best Practices documentation, tests, registry of local variables and toolkits. Thoughts/comments?
General consensus that these are good ideas. Any problems moving focus on hub implementation to email and forums? No objections.
Jon: Previously we've been meeting every two weeks. Should we go back to every two weeks as the default? Reserve this slot every week so we can meet if necessary on an off week, but default to every other.
General agreement.
Newer Activities to pay attention to (intro first):
Topic: Interoperability Charter
right now we're a committee, need to become a working group (well defined term from legal perspective). Next phone call will focus on approval process for working groups. But know we will need a charter. Jon's sketched out a first version, but haven't looked at it for a while. We need to produce a proposal and charter document to the steering committee. AI: anyone interested in helping on the proposal/charter?
Speak up now or later.
David volunteered to help.
Target completion for first week of January to have concrete proposal ready for review. (Benefit: working groups can recommend things to become standards, take materials and have them published as approved materials by the Alliance; not possible to do these things as a committee because of IP issues.)
Topic: Specification for the Hub
Needs to be written as a spec document that can be voted on and published. Jon has a skeleton outline (separate chapter for each component of the hub). AI: Please review that, should be able to flesh this out during December.
Q: What level of detail are we looking for?
Jon: Don't necessary need deep detail; but specified in enough detail to rewrite your own hub that would be interoperable with others. Also need enough specifics to test our own implementation for compliance. Length is not the goal, but completeness is.
Q: Talk about "what to do" not "how RI is implemented." Should we include testing methodologies?
Jon: Focus more on assertions that can be tested.
Q: But are we going to claim our current test suite is the conformance test?
Jon: Seems like that's what we want to do. (We'll want to make sure the responsibility for proiding conformance tests and an RI are in our charter -- similar concepts to what JCP does.)
Topic: Registry of toolkit libraries and global variables
Jon: Talked for six months about having this; need to get official registry worked on because we need that to integrate.
Jon proposed process: wiki page for global variables. Two sections (approved and candidates). Any member can add an entry in the candidate area. This committee (when its a WG) reviews candidates and has approval vote to move to approved section. We can decide later to leave wiki page as the official publishing, or later snapshot to HTML. We might want to be able to check the list in some format that can be extracted for automated testing.
Alex: Maybe store in an official JS file, and maybe that could be what you do when a particular toolkit gets approved.
(General agreement.)
Topic: Similar idea for best practices.
Jon has created skeleton wiki pages around ajax. Open Ajax conformance -- "must implement spec, must support our best practices" (and maybe some more stuff). Five skeleton pages by type for now: application developers, browsers, runtime libraries, IDEs, servers (ie products addressed in Server Task Force). Within each category, we can think of same idea ... anyone can offer candidate best practices, we formally vote on making them approved best practices.
Jon: Maybe we want to publish approved things on a separate page like we just discussed with registry.
Q: How are we going to adjudicate whether someone is conformant with best practices or not?
Jon proposal: companies claim what they want to claim, industry essentially keeps people honest.
Jon: BPs for apps are more guidelines; most won't publish claims about compliance.
Jon: Browsers ... we can use this as bully pulpit.
Jon: Primary area of influence: libraries, IDEs, servers.
AI (Jon): remove approved section, set up pointers to separate areas for approved.
(General agreement)
Topic: Acid tests
Discussion around "acid tests". Jon/Alex talked with a couple browser vendors about possibly providing such tests that browser vendors could use to evaluate their own browsers. Web standards group has stuff like this for HTML/CSS conformance. Interested in having tests and/or working with us on this. Seems like something of value to industry if we could work on that.
Jon: seems like a good thing to work on, but might have to make a priority call about working on too much stuff at once.
Kevin: good thing to work on. Isn't W3C standardizing XHR?
Alex: yes, web apis working group working on this and DOM0. Seems like acid tests might need to follow that? If so, we need different pragmatic sorts of tests versus just implementing base standards. Browser vendors need to know which usage patterns mattern because there's always tradeoffs in implementation decisions. This is more about performance than feature completion? Generality: acid tests can focus on what we think are the most important features to focus optimization/performance attention on.
AI: start thinking about this now -- probably not enough bandwidth to focus on for next couple of months. Once started, we'll need to coordinate with other groups (esp. web standards group) to work together rather than at cross purposes.
Topic: Next meeting
Jon: Next meeting in two weeks for Interop Committee. We'll need to work on charter and spec by then, plus any hub issues that happen to come up.
Reminder: development process phone call in 40 minutes.
