[Cosmo-dev] 0.6 sharing proposal

[Randy Letness]

Brian Moseley wrote:
>
> 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.
>

What about EIM records that can't be associated with an item, like 
association records?  The fact that you can have these types of EIM 
records drove me away from storing EIM records as item attributes.  
Also, it turns out synchronizing individual EIM records is a lot harder 
using Item attributes.  And not to mention if we change the way 
Attributes work, we are impacting a bunch of existing code.  Not show 
stoppers, just more work.  I tried to take an approach that would have 
the least impact to existing stuff.    The idea was to leave Cosmo 
working as is, and add in this new protocol for EIM support.  Then 
Chandler can utilize this new protocol however it wishes.  I figured 
that its not where we want to be ideally, but better than what Chandler 
is doing today, which is managing  separate .xml resources.

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

I see two ways of doing this: store the data in EIM form, or come up 
with our own schema for tasks and events and convert the EIM records 
into this new schema.  The reason we don't do this today is that we want 
to fully support icalendar,  so we just use that as our internal format 
instead of trying to transform it into an internal schema, which would 
be complicated to support all of icalendar.

> 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?
>
Not impossible, but definitely more complex.  Storing the blob seems 
really simple, but it makes Cosmo a great CalDAV server because it 
supports any icalendar data you throw at it.  Other calendar servers 
only store what they care about and will ignore stuff they don't understand.

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

Well thats good to know.  I was thinking you were dedicated to magic url 
stuff, and thought I wouldn't have much help.

> 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.
>
Yes but do we want to support the nice synchronization method that only 
sends changes to individual EIM records?  This is where it gets 
complicated. 

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

At least there are no dashes....

-Randy