Notes from Sharing Format Meeting, 10/26/2006

Attendees: MorgenSagen, PhillipEby, BrianMoseley, RandyLetness, TedLeung

This meeting was held to try to get answers to some of the questions posed in CosmoZeroPointSixSharingNotes.

The wire format of the EIM will be an encapsulation of EIM records and diffs

Q: How are invividual records groups back into items? A: Use of referential integrity

• references to dta
• records which include the schema (which describes references to other records)
• this is unspecified (as yet) in the XML formats and column proposals that have been made. This needs to be specified fully

Q: Do we plan to have record diffing from the "get go"? A: Yes, but we need to define records that indicate deletion -- defining addition records is pretty easy, but for deletion, we need "anti-data" records. For the most part, we can only add new EIM columns, which makes it easier to send diffs of EIM records.

Q: How does Cosmo cope with things that it doesn't understand, since Cosmo already has an object/data model. One example where this comes up is in many to may relationships, such as the reslationship between an item and a tag. A: Cosmo should just follow what the EIM records instruct it to do. There will probably be some fix up of stuff at the Cosmo object model layer, which is itself going to undergo large changes. A key capability is the ability to know the primary key for a particular EIM record type

Q: Will we need to support items is multiple collections, and when? A: The answer is yes, and by Cosmo 0.7. There may be some impacts of items in multiple collections on security, particularly when items are in collections owned by two different users. We may end up needin g to view each collections as its own world/sandbox.

Q: What needs to happen when the schema (say of calendar events) changes A: EIM is designed to decouple Application layer and Wire layer, so they can change independently -- this happens via the import/export code in Chandler.

Q: Suppose a collection is create by a CalDAV client and includes iCal properties not in the EIM schema (shared between Cosmo and Chandler). Now Chandler wants to subscribe to that collection? What does Chandler get? How do we determine what Chandler gets? How does Cosmo know which schema to use A: Several possible answers:

• the diff based approach of the EIM allows us to only send the stuff the Chandler understands
• Cosmo could translate between the ICS and EIM schemas - this is pain
• Cosmo could convert the ICS data into a form that could be stored in the DBMS and then reconstitute it for particular clients

We'll need to jointly design the EIM schemsa for the most common data types, probably driven from the Chandler domain model.

Q: Are we going to need to support multiple versions of the same schema in Cosmo? A: this depends on whether we want to support this use case

Q: What happens when Chandler subscribes? Is there a schema negotiation/handshake? How does Cosmo know what Chandler understands and vice versa? A: There could be a negotiation, but it may just be simpler to include the schema for each type that is the collection being subscribed to.

We need to define:

1. EIM type for referencing a field in another type
2. way for specifying EIM primary key

Q: How will we handle stamping in Cosmo/EIM? A: In EIM we will transmit different EIM records for the various stamps. PJE recommends the book http://www.amazon.com/SanFrancisco-Design-Patterns-Blueprints-Business/dp/0201616440 as a source of ideas for the Java/Object model layer. (Specifically, Chapter 16 of the book describes the "Extensible Item" pattern, which is very similar to how stamping is now being done on the Chandler side, but the book describes a way to do it in standard Java.)

Cosmo team is looking to start on EIM work immediately for Cosmo 0.6, and will be doing low level work to support items/stamping in Cosmo in Cosmo 0.7/0.8 Morgen's top priority is working on EIM stuff

Morgen and Randy to work together to plan baby steps so that we all finish close to each other.

-- TedLeung - 26 Oct 2006