[Cosmo-dev] 0.6 sharing proposal

[Bobby Rullo]

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

> On 11/1/06, Bobby Rullo <br at osafoundation.org> wrote:
>
>> I always envisioned that one day Cosmo would store everything in  
>> some format
>> that more closely matches the Chandler model, and when someone wants
>> something in icalendar via CalDAV or webcal or whatever, the  
>> appropriate
>> conversion takes place.
>
> my vision is that cosmo stores everything in whatever "internal model"
> is most efficient, and it provides a series of adapters for each
> "external model" (icalendar, vcard, eim, etc).

I'm down with that.

>
>> I think this is important because events in Chandler's world are not
>> necessarily  just events. They might also be emails and tasks and
>> lord-knows-what-else. They will have attributes that are not  
>> icalendar
>> related.
>>
>> So I'm thinking, why store all icalendar stuff in one place, and  
>> other type
>> of properties somewhere else? Why are calendar items "special"?
>
> in order to support strong etags for webdav and caldav, we need to
> guarantee that we can regurgitate the content of a resource entity in
> exactly the same byte sequence every time it's requested. in other
> words, if a client asks multiple times for a resource with a specific
> etag, we need to provide the content exactly the same every time. we
> can't (for example) arbitrarily reorder the icalendar properties.
>

Strong etags don't mean that you have return exactly what you PUT in  
right? Just that repeated GETs return the exact same byte stream?

> the easiest way to guarantee the correct behavior is to just store the
> icalendar blob and serve it up unaltered every time. i'm sure there's
> a way to decompose the icalendar blob, store the data in the db, and
> then reconstitute it so that it's byte-for-byte equal to the original
> blob, but that might be hard to program and is almost certainly less
> efficient for storage and/or querying.

Less efficient in terms of storage space - perhaps. For querying -  
not sure. But more efficient in terms of dealing with OSAF repo  
semantics - stuff like tracking changes on props and what not.
>
>
> ideally we could come up with a way to store event data in the
> database such that we can guarantee byte for byte equality with
> multiple icalendar conversions without sacrificing too much in terms
> of storage. that would let us write (relatively) simple converters for
> eim<->database and icalendar<->database.

Yeah, that's what I'm talking about.

bobby