[Cosmo-dev] 0.6 sharing proposal

[Brian Moseley]

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

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.

> Now reading between the lines of what Randy wrote ("Ideally we need a way to
> transform EIM data into CalDAV resources (CalendarItem? in Cosmo) and
> vice-versa") I am thinking that this is just a temporary stopgap until we
> have everything stored in one sort of unified way and stop thinking of
> events as special. But I don't want to assume anything, and I'm not sure if
> Brian shares this vision, and if not, why.

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.