[Cosmo-dev] 0.6 sharing proposal
bcm at osafoundation.org
Wed Nov 1 16:19:49 PST 2006
On 11/1/06, Randy Letness <randy at osafoundation.org> wrote:
> What about EIM records that can't be associated with an item, like
> association records? The fact that you can have these types of EIM
> records drove me away from storing EIM records as item attributes.
add a new table to store these. we can do the minimum possible work
for these, just enough to be able to regurgitate them for sync
requests, because cosmo itself is not going to have to understand any
semantics for these things (at least i can't think of any data types
that we have considered building support for in the next year that fit
> Also, it turns out synchronizing individual EIM records is a lot harder
> using Item attributes.
> And not to mention if we change the way
> Attributes work, we are impacting a bunch of existing code. Not show
> stoppers, just more work. I tried to take an approach that would have
> the least impact to existing stuff. The idea was to leave Cosmo
> working as is, and add in this new protocol for EIM support. Then
> Chandler can utilize this new protocol however it wishes. I figured
> that its not where we want to be ideally, but better than what Chandler
> is doing today, which is managing separate .xml resources.
see, i don't think minimizing impact is an important goal. getting the
right interface between cosmo and chandler is most important, imo.
> I see two ways of doing this: store the data in EIM form, or come up
> with our own schema for tasks and events and convert the EIM records
> into this new schema. The reason we don't do this today is that we want
> to fully support icalendar, so we just use that as our internal format
> instead of trying to transform it into an internal schema, which would
> be complicated to support all of icalendar.
not really. icalendar breaks down very simply into components,
properties and parameters. at the end of the day, they're just
name/value pairs. look at our calendar index table. looks an awful
like the attributes table :)
strawman: add "properties" and parameters" tables, each with name,
value and order columns. items can have 0..* properties. properties
can have 0..* parameters. now we have enough information to
reconstitute the icalendar object that was originally given to us.
hell, we can probably get rid of the calendar index table and query
against these two instead. and we can certainly convert "item" eim
record types to/from this structure.
> Not impossible, but definitely more complex. Storing the blob seems
> really simple, but it makes Cosmo a great CalDAV server because it
> supports any icalendar data you throw at it. Other calendar servers
> only store what they care about and will ignore stuff they don't understand.
there's no reason we can't continue to support arbitrary icalendar
data. properties and parameters and string values are easy to store as
i suggested above. cosmo doesn't have to grok a property in order to
be able to store it.
> Well thats good to know. I was thinking you were dedicated to magic url
> stuff, and thought I wouldn't have much help.
i think the majority of the work will be in bobby and matt's domains.
> Yes but do we want to support the nice synchronization method that only
> sends changes to individual EIM records? This is where it gets
it's nice to have but not necessary. if a sync only includes the
records for changed items, that's a huge win in and of itself. we can
look at doing record-level diffs in the future.
More information about the cosmo-dev