[Cosmo-dev] Cosmo 0.6 sharing

[Brian Moseley]

On 10/24/06, Randy Letness <randy at osafoundation.org> wrote:

> That makes more sense, but from the EIM example, there are no
> "note" records as note just inherits from "contentitem", but adds no
> additional fields.  Maybe the example is wrong, or maybe a
> contentitem is a note by definition.

ah, gotcha. i'd suggest that for symmetry's sake we have a note
namespace and record type, even if it doesn't add attributes.

> So we have to have some sort of EIM-->icalendar and icalendar-->
> EIM translator to support other protocols like CalDAV.  Since all
> the calendar events are indexed using the icalendar properties, it
> seems like we would need to create an icalendar representation
> of the EIM records in order to continue to support CalDAV.  This
> brings up another question.  What if people want to use Cosmo
> only as a CalDAV server (no Chandler involved)?  Should Cosmo
> still decompose the icalendar data into EIM records.  Is
> Cosmo basically turning into an EIM repository with hooks
> to support getting/putting data using other protocols?

well, i think there are two ideas here:

1) we need to gateway morse code to/from our internal model
2) we could potentially make our internal model look like or be EIM

caldav is orthogonal to morse code. they are both protocols that move
data formats (icalendar, eimml [yuk yuk]) to/from the server. we need
to be able to convert our internal model to/from both of those formats
(and hcalendar, and gdata, and maybe xcal, and so on).

the complicating factor i think is that for caldav we don't actually
convert the icalendar data into a stored representation and then
convert the stored thing back to icalendar. we actually store the
icalendar data itself and then send that exact same sequence of bytes
back. so an event created with caldav but shared with morse code needs
to get converted from icalendar (an ical4j object) to eimml rather
than from a CalendarEventItem.

> The example I was thinking about was an item with association
> records.  Each association (tag for instance) is represented as
> a record, so an item can have any number of association
> records, all with the same namespace, just different values.

hm, then maybe we don't model those assocations as attributes?