[Cosmo-dev] 0.6 sharing proposal

[Bobby Rullo]

I like your first approach, which is what I think I was getting at  
loosely, but I don't understand the second approach. Could you  
explain it, even though it's not the one you are advocating?

Bobby
On Nov 1, 2006, at 5:29 PM, Brian Moseley wrote:

> On 11/1/06, Randy Letness <randy at osafoundation.org> wrote:
>
>> The complexity comes in when Chandler wants to store extra data  
>> (like it
>> does today in the separate .xml resources).  This "extra" data that
>> isn't stored in the icalendar blob would have to be stored in EIM  
>> form,
>> since Cosmo doesn't care about it (yet).   So we have to store the  
>> EIM
>> records in Cosmo if we want to send back the same data.  What about
>> collections other than calendars?  These will be EIM records that  
>> Cosmo
>> doesn't understand, and has to just store and regurgitate in a  
>> generic way.
>
> that's why we have item attributes. you've listed some of the ways
> we'd have to extend attributes so they could support eim, but none of
> them seemed like showstoppers to me.
>
> let's say that chandler sends us an event record and a task record for
> the same item. as i mentioned earlier, ideally we could take all of
> the event and task info and put it into the database in a way that we
> could later  reliably reconstitute an icalendar version of the item
> (containing a VEVENT and a VTODO) that is byte equal every time. this
> implies that we don't actually store any content for the item, btw!
>
> if we can't figure out how to do this, then instead we can just take
> the CalendarItem we create out of the event+task, convert it to
> icalendar, and write that as the item content so we can serve that
> instead. but really, the more i think about it, the more i'd prefer
> the earlier approach. we're already indexing the event properties,
> which means we're paying the storage cost for them. can it really be
> impossible to store a little more info that helps us rebuild the same
> icalendar strin