[Cosmo-dev] 0.6 sharing proposal

[Brian Moseley]

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 string out of the database every time?

and yea, there's gonna be a bunch of work, but i should be able to put
75-100% of my time into this as well as 100% of your time. so let's
not get overwhelmed by what seems like a big job right now. let's just
spec it out and see how long we think it will take and *then* think
about what we can cut, but only if we need to.

> Now if we don't care about generic EIM support (ignore records we don't
> understand), then we can do what you suggested, and it would be pretty
> straightforward as you noted.  I was thinking that for 0.6 it would be
> cool to support the sharing of any collection type in Chandler,
> including new types added by add-on parcels and such.  The separate .ics
> resources only come into play for calendar collections.  The idea I had
> in my head for 0.6 is to provide this protocol for
> sending/retrieving/syncing EIM records.  Then we add more smarts into
> Cosmo to handle recognized record types (events, contacts, whatever) to
> support CalDAV and other protocols.

the majority of what alpha4 will share to 0.6 is calendar data. yea,
there will probably sbe some non-calendar stuff in some of those
collections, but events will predominate. so we should focus on making
events work really well and doing just enough work that we can spit
non-event stuff back to chandler even if we do nothing with it in
cosmo other than store it in the stupidest possible way.

> I agreee, uid is the way to go.  We need to come up with a URL friendly
> uid format.

as an example, here's the public address for one of my google calendars:
<http://www.google.com/calendar/feeds/kj8q4h3g4ob5lp0d5517vp4614@group.calendar.google.com/public/basic>

it's not immediately clear how they generate that uid, but it's not
particularly more friendly than the one we're using right now.