Where will the Scooby tasks be tracked?

• Bobby asked about bugzilla
• whatever the team decides to do is fine
• for now, wiki tables as in ScoobyReleaseForTargetUser is fine

Discussion of how Matt and Bobby are coordinating data persistence

• and what remoting framework to use
• ideally a high-level API that abstracts away XMLHTTP reqeusts

Discussion of data formats

• Could use iCalendar -- not that bad to write data parsing in JavaScript
• Could use xCalendar or our own variant of iCalendar semantics in XML syntax.
• Data format translations should be delegated to Cosmo whenever possible
• This is mostly an implementation detail for transport -- for most purposes, an Event will be an object on either side.
• The object API should be roughly compatible with iCalendar semantics unless we need to diverge for our custom features.

Licensing discussion

• JSON is LGPL... Bobby will send the license to Sheila for examination

Zimbra

• Do they support WebDAV? No hint of this although theoretically to drop in as an Exchange replacement they'd have to.
• Don't support CalDAV...
• Could Chandler share heterogeneous collections of arbitrary documents on Zimbra?
• Only on Linux (specific builds only)
• Merits further investigation as a platform (repository) for Cosmo
• Certainly lisa should contact to talk about CalDAV at some point

Version hell

• For Cosmo, we have 0.2, a branch from there for 0.2 patches, and the trunk has 0.3 work.
• On cosmo-demo we have port 443 running 0.2 and port 8089 running continuous builds of 0.3 trunk.
• On QA-cosmo server we run 0.2 only for now.
• Chandler builds have account information that points to port 443 of cosmo-demo server.
• Some debate about whether we've got patches installed on 0.2 (port 443) of cosmo-demo.
• Morgen and Grant sometimes test against yet other builds of Cosmo installed on their own machines, because BCM is fixing bugs for them on the 0.2 branch.
• Builds of Cosmo will be validated by Aparna before we upgrade the version on 443.
• One proposal is that Aparna should only need to upgrade QA-Cosmo and run against that when we're validating a build of Cosmo and considering upgrading the main cosmo-demo port to that validated build. The rest of the time Aparna should save work by testing against cosmo-demo.

• Do people have a decent understanding of what state Cosmo is at? we've just discovered it's not ready for dogfood prime-time, is that broadly understood?
• Lisa should send email characterizing the robustness of sharing (restating the starred items in this conversation).
• M6 should not be released until Chandler's sharing URL points to something that passes Aparna's smoke test.
• Is it reasonable to fix the Cosmo bugs in time for M6? Not unless we know the complete list of bugs -- right now they're being flushed out by features being added in Chandler right up to the M6 deadline. So this puts M6 at risk.

• Should we add another port with another version to cosmo-demo server? one that points to the latest build (unvalidated) on the 0.2 cosmo branch? There's an open ticket so, yes.
• we need to know more clearly when we need to wipe Cosmo server data.

• Sheila will create a page with the status of builds on cosmo-demo and will update that weekly (triggered by this meeting)