[Cosmo-dev] 0.6 sharing proposal

[Brian Moseley]

On 11/1/06, Randy Letness <randy at osafoundation.org> wrote:
> I started a page
> (http://wiki.osafoundation.org/bin/view/Journal/CosmoZeroPointSixSharingProposal)
> outlining what I think sharing in Cosmo 0.6 means.  After talking with
> Morgen, Philip, Brian, and Ted last week I realized sharing is a big
> problem to solve.  Instead of trying to solve the problem in 0.6, I'm
> proposing we take steps by providing certain functionality in phases.
> The wiki page outlines what I think is feasible to complete in the first
> phase (0.6).  There are still some unknowns, and hopefully everything
> will be flushed out next week while I'm in town.

i agree that we probably need to work on sharing in stages - that's
always been my expectation. however, i think that our highest priority
is to stabilize the interface between chandler and cosmo as soon as
possible. the fewer times chandler has to change, the
better. for that reason, i think we should focus our efforts on
getting the protocol and interchange format right from the beginning.

your proposal for publishing a collection has chandler doing a single
put for the eim record stream and then another put for the icalendar
version of each item. i understand why you made this suggestion, but i
don't think it's right. from the get go, publishing a collection
should be a one request operation, and it should only involve eim
records - no icalendar at all.

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.

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>

when publishing, if no parent uid is specified (which will be the norm
for chandler, i think), then cosmo will make the home collection the
parent of the new collection and will name the new collection using
its uid. thus, the new collection will be available via dav at
/cosmo/home/user/<collection uid>.

if the eim stream includes a record for the collection itself that
sets  its name (eg "My Calendar"), then the collection will be
available via dav at /cosmo/home/user/My%20Calendar instead.