Attendees

• Brian, Morgen, Randy, Ted, Grant, Phillip, Katie

Agenda

• Sharing protocol
  • CosmoZeroPointSixSharingProposal
  • http://lists.osafoundation.org/pipermail/cosmo-dev/2006-November/001875.html
• EIM record proposal:
  • MorgenSagen20061106

Notes

• When client PUTting new collection, client responsibility to name it uniquely. (error if that name already exists)
• Mk ticket and verb we use today.
• Collection EIM meta-record to designate freebusy.
• Philosophically, not trying to replace all of DAV
• Need to define a deleted item record.

• In order for syncing collection to understand an item has been deleted, need to keep tombstone record around. At what point can we remove that record from storage, the server. Possible answers: until collection deleted? one year? How frequently are items deleted/how many deleted items? Open Issue. Server side issue, will only matter to the client if the client syncs very infrequently (once a year). Morgen: could associate with each syncid a timestamp. BCM: subsecond resolution on sync times? Will people ever be syncing twice within the same second? Two updates? One way to implement the sync token is with timestamp, millisecond granularity. Can then detect an old sync. Could ask the client to reGET the whole collection/full update.

• BCM: Publish and Update: what happens if there is an error? rollback operation? error on one particular record?
  • Morgen: first thought, should be atomic. If one thing fails, roll it back.
  • BCM: acceptable to say all of sharing failed, try again? easier if we do that, avoid multistatus response.
  • Morgen: yes, all or nothing, atomic.
  • BCM: easier to implement.
  • Ted: Is this a design question?
  • Morgen: I think they want consistency. Right now we just abort a failure anyway.

• BCM: Two clients are trying to update a client at the same time? One wins?
  • Concurrent mods to same collection. Investigate server reject any updates beyond first with status code and message for client to try again soon. Implicit lock on server side, no unlock (end of PUT). Subsequent concurrent posts to same collection get rejected. Locking on the post but not on the put.
    • Delete? Delete needs to fail if another client is posting. Open Issue: Get during delete.
    • Get during post: get will still get data before the post.

• Subscribe is just a GET for collection's UUID, will return record stream for everything in collection, will give data in arbitrary order regardless of items in the collection.

• Sync will be a GET. All information since that sync token was generated. Will give entire record for every item that has changed, not the diff. Entire state of the item. If items have multiple records, will give all records. If item is deleted, keep a tombstone record in db.
  • Sync token: PUT and POST and GET? In response of PUT and POST, client will get a new sync token. On every GET, server will send token back, regardless whether anything has changed. Not DELETE. Sync token will likely be a response header. Want to keep the payloads as simple as possible. Just the records and nothing else. Only have to look at headers in the URI and not the payload.

• Security: basic authentication + tickets (just like with DAV). Basic auth wins if ticket and basic auth.

• EIM record for the collection itself? If so, use the record for the name of the collection. We do have other metadata currently in share.xml collection, about share itself: Name, filtering information (only share events/tasks or some other subset), what attributes are being shared or not shared (user can decide to not publish alarm or triage status). Can add a column for name for that record type. PUT specifying UID for collection, can set a name for it with the record.
  • Open Issue If there are records in the EIM stream about the collection itself, some of those items are in the collection, some of them are secondary items along for the ride. Need to think about that, how to determine which items are in the collection. A separate record? BCM: assume secondary items somehow serialized. BCM: In 0.7, will support an item soup, will break item off and it will go into the soup.
  • Decision EIM record to store metadata about collection itself.
  • UID oriented address and Path oriented address will both be supported.

• Only datatypes supported are Items
  • Ted: how to model tags? We talked about modeling it as a collection, so shouldn't be a problem.
  • Morgen: 2ndary item: lastmodifiedby --> reference to a contact item currently. That contact is not in the collection. We could get way with storing as an email address, will simplify things, will get us the funtionality we need. BCM: would there be any harm in them being an item in the collection? Morgen: yes, don't want a contact in the collection. Morgen: emailaddress gets linked up to a collection on the other side.
    • BCM: what about putting a contact collection in the server? Reference in calendar collection a UUID reference. Cosmo UI could display it, can follow UUID and get contact. Puts more work on sharing. For 0.6 we need every item to live in a collection. Ted: In chandler, a Kind collection is a collection of all items of a particular kind. BCM: concerned about migrating. Katie: Ok to not backward compatible before Preview, so fixed by 0.7 is fine.

EIM Records

• Is Cosmo team going to know all the record types before hand? Anything we don't know we just ignore? Chandler won't send those?
  • Task will have an iCal UID (vTODO). Notes probably need an iCal UID as well (vJournal). Task has a due date, but we are not using it.
  • Better to create a Task record and add iCal UID into that? Emit a task record, and event record with same iCal UID? Both types need an iCal UID.
  • calendar item record, includes fields that belong to both like iCal UID.
  • Task/Event extend Note in our domain model. If not a task or event, by definition a Note. Note could have iCal UID.
  • Proposal Move iCal UID to Note.
  • Implies rules about records emitted together. Cal Events must be Note + Event records.
  • What goes in Task record? At the moment nothing.
• What happens if someone unstamps? Unstamp record? Delete record of that same type? Imply there is a deletion flag for any record?
  • deletion flag for event record means it is no longer an event. Deletion flag for note means the thing is deleted completely.
  • Reason to have seperate item record from note? Ted: In Chandler: Item --> ContentItem^? --> Note. Could collapse these to Note, Note is top of stamping hierarchy. BCM: interest of future expansion, don't collapse them. Let a window for Items that are not Notes.
• Contact record: this may just go away.
  • What about things with 1:many relationship? E.g. attendee. Emit each attendee.
  • Does it make sense to have a contact record? email address is foreign key? Set of contact records associated with event? Notion of multivalued attributes ok in Cosmo.
  • Could store an attendee item that is not in the collection. As long as we don't need to query contact info, should be able to just regurgiate it to you. Could just serialize it and stuff it. Morgen: How do we know contact items should not be in collection? BCM: Cosmo doesn't think of contacts as items. BCM: what if there are other secondary items? Morgen: pretty sure no other ones. BCM: that means we don't need a contact record at all.
• Triage record. BCM: could we just have two attributes on Note record? Ted: What is the rationale for separate record? Morgen: thought they were part of a stamp.
• Types:
  • triage is a float? should be a datetime. The UI wants to display a datetime. If it represents a datetime, lets use datetime.
  • Datetime: does it have a timezone attached? Sufficient to always express datetime in UTC? PJE: thought they would include timezone name (Olsen) and also always include UTC offset of that particular datetime. BCM: could simplify using only UTC. PJE: problem is roundtripping, in a particular timezone is important to the user. Need to keep timezone name.
  • Grant: Recurring events might have subtle issues if you rely on offset. May change twice a year with daylight savings. Olsen is fine as long as you don't have to fallback on only the offset. Grant: one of those things to note and move on. First step on road to what iCalendar has become.
  • Randy: Multivalued properties like rules and exception dates? Morgen: Hoping fields we pick would map incredibly closely to iCal. BCM: to get started, use iCalendar syntax. If it won't work, come back to it. Possible to have multiple xdates. Multiple xdate properties in the iCalendar stream. rrule, xdate, rdate records associated with the items. Randy: or write them all out and delimit them in some way. Grant: Chandler doesn't generate rdates, but does understand them. Morgen: need records for rdate and for xdate.
• xcal, ical, gdata: normalize it, convert it into EIM. Potentially additional data not part of this record type. E.g. iCalendar xproperty that someone else has defined. Does Chandler want it? For now, no.
• Randy: our collections are typed, calendar collection and regular collection. Morgen: can only an event be added to a calendar collection? Randy: we need it to support CalDAV, CardDav^?. Morgen: what would you recommend Chandler specifying? BCM: Isolate Chandler from this altogether. Randy and BCM to figure out how to massage this for CalDAV/CardDAV. Right now we do both Mkcol and mkcal, giving Morgen grey hair.
• Terminology: Protocol itself as MorseCode^? as working title. Serialization is EIM.
• RecurrenceID^? is actually a datetime. Rrule, xrule should be text. iCal UID a text (not UUID).
• Anytime and allday? Grant: allday, write things out as a date. Morgen: does EIM have a boolean? or should we use an int? BCM: why the boolean? We write out an x-osaf-anytime property. Might be to be compatible with iCal. Will leave out allday/anytime bits. Grant will look up what iCal does. Easily convertible to iCalendar as possible is a guiding principle for making these decisions. Enables Morgen to reuse vobject code.
• description will be deleted (use Body which is already there)
• Enumerations? Express as integers or strings? Strings makes it more human readable. BCM: can Chandler folks document/publish as part of record types? BCM: any need to validate data out of Chandler? Morgen: might want to validate the status -- if you turn around and hand data to another client, may want to validate against that. BCM: client can define x-status. Ok for Cosmo to tell Chandler a status that Chandler doesn't know about? Morgen: Don't know how this interfaces with iCalendar. Possible for clients to define their own. Decision Cosmo will not do the validation, up to clients.
• xrule/rrule: broken out or part of event record? xrule/xdate, rrule/rdate: will be own record. Randy: how to update? Morgen: how to do a diff on multivalued attribute, without listing all of them? Deletion records for ones no longer valid. BCM: wonder if we shouldn't have UUIDs for these things as well, in terms of referencing things. BCM: lets do it the simple way now. Morgen: what if we took 4 attributes and just stored each as string w/delimiters? BCM: sure, lets try it. Non elementary data type.
• BCM: Need to accurately match creation time and last modified time Chandler/Cosmo? Doesn't make sense in sharing context.
• Grant: will have a createdon date in Chandler.
• MailMessages^?: use serialization format RFC822? Body a LOB type. Morgen: confused about how body attribute works in Chandler. Might be separate field for mail message record.
• BCM: versioning? worry now? later? In short term, releases will be sync'd.

Serialization for data format

• Deleting a specific attribute? Does it make sense to delete attribute vs setting it to Null/None? Wrinkle, won't be emitting alarm record even though it does exist. BCM: could put an attribute on any of these elements: delete==true. Removing an rrule -- find that rrule in the db, might compare iCalendar string value. Or, replace entire event object. BCM: argument for making rrule its own record, can give it a primary key, do that association very easily. Either an attribute or child element for deletion of attribute.

• BCM: objection to XML schemas for record types? Morgen: not if you do them!

• Morgen: What will tokens look like? BCM: Will look like strings.

Next actions

• BCM:
  • spec out protocol, xml (including deletion)
• Morgen: (alpha4 bugs to fix, will get to working on EIM stuff as soon as he can)
  • define EIM record type for collection itself (filtering, freebusy)
  • EIM notation for deleted record
  • rewrite sharing.py file
• Randy:
  • work on storage
• PJE:
  • import and export framework