[Cosmo-dev] 0.6 sharing proposal

[Randy Letness]

Brian Moseley wrote:
> not sure what you meant by multiple locations. records we can
> associate with items get applied to those items; records we can't
> associate with items get dumped into a bucket so we can spit them back
> out, but we don't do anything else with them.
I was thinking about tracking changes to these records.  If only a 
single non-standard record has changed, then we want to be able to only 
return that record on a sync call.  Cosmo needs some logic to determine 
if an individual record changes.  We could track changes to Attributes, 
and if we map records to attributes we could track changes to records.

> i really hope not. i think we should work towards a core object and
> data model that is eim-unaware.
>
Yes I agree.  EIM should only be used by the sharing protocol.

>> Yeah we could do this, but we are talking about a lot of work.
>
> really? maybe i'm spoiled by how fast you did the original hibernate 
> work :)
>
Before jumping into Cosmo at SimDesk, we actually thought about coming 
up with a full icalendar schema, but after realizing how complex it 
would be, decided we liked Cosmo's idea of storing the icalendar blob.  
But, we were most concerned with performance and preventing data loss.
 
>> And 3 levels of tables (components, properties,
>> params) would result in some nasty queries.
>
> nasty in terms of query formulation or performance?
>
Probably both.  Right now we are querying against a single table because 
the icalendar data is flattened into simple key,value pairs.  Of course 
the majority of queries aren't that complex, but for some reason I have 
the picture in my head about something like:

<C:filter>
  <C:comp-filter name="VCALENDAR">
    <C:comp-filter name="VEVENT">
      <C:comp-filter name="VALARM">
        <C:prop-filter name="...">    
          <c:param-filter name="...">
          </c:param-filter>
        </C:prop-filter> 
      </C:comp-filter>
    </C:comp-filter>
  </C:filter>
</C:filter>

I guess we don't have to optimize this case...just support it, even if 
it means slow perf.

> overall, i think it would make sense to do a thorough examination of
> the chandler domain model and repository to see what we can learn from
> them. it may be that our domain model needs to start to look more like
> chandler's in order to cope with all this new stuff.
>
Yep, but one thing we need to keep in mind is that Chandler is for the 
most part a single user app, so they can do some crazy abstract stuff 
and not have to worry too much about performance whereas Cosmo needs to 
potentially support thousands of users.

-Randy