[Cosmo-dev] 0.6 sharing proposal

[Randy Letness]

Brian Moseley wrote:
> 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
> this description).
>

Then we have things stored in multiple locations, and have to deal with 
syncing them...i don't know, seems painful.  I'll think about it some more.

>> Also, it turns out synchronizing individual EIM records is a lot harder
>> using Item attributes.
>
> how so?
>

I guess its similar if we can store everything as an attribute, but if 
we have to store records in multiple places, it gets complicated.   We 
would also need a way of identifying an item attribute as an eim 
record.  Maybe we could create an EIMAttribute type.

> 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.
>

Yeah we could do this, but we are talking about a lot of work.   And 
icalendar has no constraints on lengths of things, so we would either 
have to truncate large values or store everything as a text field in the 
db, which slows things down when searching (some db's don't even support 
searching text fields).  And 3 levels of tables (components, properties, 
params) would result in some nasty queries. 


>> Yes but do we want to support the nice synchronization method that only
>> sends changes to individual EIM records?  This is where it gets
>> complicated.
>
> 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.

Yeah I hadn't thought about record-level diffs yet.  That is another can 
of worms as you would have to keep track of all changes to a record 
instead of just the action (add/delete/modify).

-Randy