[Cosmo-dev] 0.6 sharing proposal

[Randy Letness]

Brian Moseley wrote:
>
> reading between the lines, i sense that you are worried about how to
> deal with chandler publishing only an eim record stream given that we
> store event info in an icalendar blob rather than as discrete database
> columns, but i'm not sure why. it seems straightforward to me for the
> chandler and cosmo teams working together to define an eim event
> record type that we can convert into icalendar format and store in the
> event item's calendar blob. it also seems straightforward given the
> existence of such a record type to convert an icalendar blob into a
> set of eim records to send back for subscription requests. there
> certainly doesn't seem any need to store eim records in the cosmo
> database.
>
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.

Ideally, Cosmo will be able to convert from recognized EIM record types 
to icalendar and from icalendar to EIM records, but I was leaving that 
out for the first phase due to the short release cycles we are aiming for.

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.
> also, let's not use hierarchical paths for morse code urls. the future
> is the item soup, so let's start building our protocols with this in
> mind. here's my proposal for the protocol commands:
>
> publish: PUT /cosmo/mcp/collection/<uid>?parent=<parent uid>
> update: POST /cosmo/mcp/collection/<uid>
> delete: DELETE /cosmo/mcp/collection/<uid>
> subscribe: GET /cosmo/mcp/collection/<uid>
> sync: GET /cosmo/mcp/collection/<uid>/?sync=<token>
>
I agreee, uid is the way to go.  We need to come up with a URL friendly 
uid format.

-Randy