[Cosmo-dev] Cosmo 0.6 object model changes

[Randy Letness]

Brian Moseley wrote:
> wait .. if EventStamp has all the event properties on itself, why
> would it ever need attributes? seems to me with the model you've
> diagrammed, attributes are only ever needed for dav properties...
>
The nice thing is that you can do either.  You can have a stamp that 
stores its data as separate fields, or as attributes on the item.  Right 
now I'm thinking that the stamped data will not be stored as attributes, 
but its possible. 

> how about just adding an order column to the current index table and
> writing code to build an ical4j object out of it? then we wouldn't
> have to store the icalendar blob (saving storage space) but could
> reconstitute (and cache) it when needed. when accessing the item with
> webdav or caldav, we could just write out the icalendar object rather
> than pulling the content blob out of the db table.
>

That works until you have to store property names or values that are 
bigger than what the index table can handle.  We truncate values in the 
index table and ignore property names.  To be 100% icalendar compliant 
we would have to use text fields to store the key/value pairs, which 
prevents efficient indexing/searching.

> i guess just adding an order column isn't enough. we need enough
> information in the key to be able to associate any given index item
> with its original icalendar component (the enclosing vcalendar, the
> vevent, any enclosed valarms and vtimezones, etc) and order the
> component within the object, the subcomponent within its component,
> the property within its component, the parameter within its property.
> annoying but probably not too hard eh?
>

With the order and the current way the property keys are stored 
(flattened hierarchy), this shouldn't be too hard, although it would be 
a lot of parsing.

> if caldav is used, we should probably both create/update the
> EventStamp and store the icalendar (as blob and/or as proposed above).
>

Yep.

> i think chandler still wants to see items even if they aren't stamped,
> doesn't it? if somebody uses dav to overwrite an event with a jpg,
> that would remove all of its stamps, and the next chandler sync would
> note that and suck down the new data. i guess we need to clarify this
> with morgen etc.

Does Chandler care about a file that is created using DAV?  I thought 
all Chandler cared about was Notes,Events,Tasks, and Messages.  So if a 
DAV client creates a .jpg in a shared collection does Chandler even want 
to know about it?  Do we even allow this?

-Randy