Interoperability Minutes 2006-08-16
From MemberWiki
Full minutes: http://www.openajaxalliance.org/member/wiki/index.php/Interoperability_Minutes_2006-08-16
Attendees
- Alex Russell <alex@dojotoolkit.org>
- Adam Peller <apeller@us.ibm.com>
- Arno Puder <arno@puder.org>
- Bjoern Mueller <Bjoern.Mueller@softwareag.com>
- Chris Jolley <jolleyc@bea.com>
- Chris Matthews <cmatthews@elinkbiz.com>
- Erik van Dongen <evandongen@seagullsoftware.com>
- Greg Murray <greg.murray@sun.com>
- James Margaris <jmargaris@nexaweb.com>
- Jon Ferraiolo <jferrai@us.ibm.com>
- Kin Blas <jblas@adobe.com>
- Lindsey Simon <lsimon@finetooth.com>
- Phil Berkland <berkland@us.ibm.com>
- Rama Gurram <rama.gurram@sap.com>
- Steve Adams <sadman@curl.com>
- Ted Thibodeau <tthibodeau@openlinksw.com>
Gustavo Munoz <gustavo.munoz@jackbe.com>
Absent
- Bert Halstead <rhh@curl.com>
- Brodi Beartusk <bbeartus@bea.com>
- Chris Schalk <chris.schalk@oracle.com>
- Coach Wei <coach@nexaweb.com>
- Craig McClanahan <craig.mcclanahan@sun.com>
- David Frankel <david.frankel@sap.com>
- David Kranz <kranz@curl.com>
- David Temkin <temkin@laszlosystems.com>
- Eddie O\'Neil <ekoneil@bea.com>
- Eric Nguyen <ericn@mercedsystems.com>
- Gary Horen <ghoren@bea.com>
- Hyther Nizam <hyther@adventnet.com>
- Ian Wenig <ian@zoho.com>
- James Douma <jdouma@ebusiness-apps.com>
- Jason Wadsworth <wadsbone@thefrontside.net>
- Javier Gallego <Javier.Gallego@softwareag.com>
- Jennifer Taylor <jetaylor@adobe.com>
- Jeremy Chone <jchone@adobe.com>
- John Crupi <john.crupi@jackbe.com>
- John Janetos <jjanetos@laszlosystems.com>
- Joonas Lehtinen <joonas.lehtinen@itmill.com>
- Jorge Taylor <jotaylor@adobe.com>
- Juan Dexeus <Juan.Dexeus@in2.es>
- Ken Fyten <ken.fyten@icesoft.com>
- Kevin Hakman <khakman@tibco.com>
- Kingsley Idehen <kidehen@openlinksw.com>
- Luke Birdeau <lbirdeau@tibco.com>
- Marc Englund <marc.englund@itmill.com>
- Michael Peachey <mpeachey@tibco.com>
- Patrick Chanezon <chanezon@google.com>
- Raju Vegesna <raju@zoho.com>
- Ross Dargahi <ross.dargahi@zimbra.com>
- Ruben Daniels <ruben@javeline.nl>
- Rüdiger Herrmann <rherrmann@innoopract.de>
- Sami Ekblad <sami.ekblad@itmill.com>
- Steven Pothoven <pothoven@us.ibm.com>
- Vishnu Vettrivel <vvettrivel@vircon.com>
- William Shulman <will@mercedsystems.com>
Agenda
Next face-to-face
- Are people available October 5-6 (Thursday/Friday, right after AJAXWorld conference) for next face-to-face meeting, presumably in Silicon Valley?
oct 5-6: general agreement
looking for hosts for ~50-150. no agenda yet.
Open Source Development Requirements - Process for developing our open source JavaScript
- At the Declarative Markup committee last week, we discussed Apache vs SourceForge vs other.
consensus from markup committee: not set up infrastructure. leverage existing (apache/sourceforge)
q: whether anyone wanted apache? Nexaweb very much in favor
james: already working on xap in js domain. realizes the overhead at apache.not set on it
jon: likes apache's organization
Adam: had bad experiences. found that religion and politics got in the way, but that may have improved. this project may also not be a natural fit for apache (javascript) and therefore may run into resistance or confusion
Adam: if we need credibility/reputation, ok, but is the apache org redundant with ours and guidance may only get in the way? sf is infrastructure only
q: are we at best practices level, rather than product? Does that even belong in Apache?
q: wouldn't we have to wait for incubator, no guarantees, etc? why not use sf in the meantime?
alex: they will look for community, bug tracking, the "apache" way, etc.
james: possible to start with a small codebase or no codebase, but apache is set up to assume an existing body of code.
james: need to add members through meritocracy, approval process. a lot of overhead for a code body which may change rapidly in its mission
james: apache wants decision making process done over their mailing lists; our decisions are made in irc and our calls outside the context of apache. that might not sit well
jon: consensus of starting in sourceforge, then possibly moving to apache down the road, aligning with apache to facilitate this? e.g. use svn instead of cvs
jon: shall we propose this?
alex: apache might be suboptimal when it comes to neutrality
jon: will e-mail the list, look for objections, and take action on setting up a sourceforge project if no objections
jon: not ruling out apache, but for reasons stated here, starting with sourceforge
How do we host mailing lists?
- OK to use yahoogroups for maillists (public and private)
jon: for mailing lists, why not use yahoo groups?
jon: with sourceforge, we could use sourceforge mailing lists.
alex: sourceforge hosts mailman
q: yahoo is a member, sourceforge is not. good for neutrality to use sf
(Note: see discussion of web site for more about mailing lists)
Review Alex's work on the event hub
alex: swamped. no developments.
Review Lindsey's work on JavaScript toolkit registration and collision detection/prevention
- (user: oaa, pass: oaa)
lindsey shows registration mechanism (oaa.js) based on alex's work
jon: likes order n
lindsey: tool for the developer, not something you'd deploy
james: registering multiple times is something we'd want to allow. dynamic loading, like dojo, might declare globals as it downloads? overlaps of variables within a toolkit are ok and not a collision.
lindsey: trust that toolkits are consistent within themselves
james: perhaps a warning is ok
lindsey: other idea - provide global detection even if the toolkit does not
alex: for compliance, keep the list of globals around and be able to pull it remotely and diff globals
provide guidance for people writing new code, know what to avoid
jon: toolkits we don't support, like prototype, we can provide data to use "at own risk"
Website status
jon: go public with website 8/31 or so. staged and almost ready.
jon: no facility for mailing lists or blog - yet. sourceforge may be good for discussion around source code, but for discussion around alliance, we might need something else
?: we should leave decisions about public mail lists to the Marketing Committee
Next Steps
james: eventually need to get into licensing, copyright ownership, etc. if we host on sf
alex: is that being addressed elsewhere?
jon: IBM likes Apache v2. others are discussing this
lindsey: let marketing committee figure this out
