[Cosmo-dev] Sharing format questions

[Brian Moseley]

On 7/18/06, Morgen Sagen <morgen at osafoundation.org> wrote:

> 1. How do we deal with 'secondary' items? Are they separate resources
> on the server, or do they get embedded within the 'primary' items'
> resource? If the latter, do we live with the duplication of
> 'secondary' items that are associated with multiple 'primary' items?
> For example, the organizer and invitees of an Event item (primary),
> are Contact items (secondary). It's likely that a given Contact item
> will be associated with many Events, so do we devote separate server-
> side resources for each Contact?

i guess there are two kinds of secondary items: references to other
primary items with uids, and simple little objects like (first name,
last name) that only have meaning within the concept of the primary
item and aren't uniquely identified with a uuid. hibernate calls the
latter "components" - maybe we should too?

we definitely should not duplicate primary items within other ones,
but rather refer to them, presumably by uuid. since components are by
nature tied to their primary items, tho, they can be inlined with
their primaries.

side question about chandler uuids: are they unique within a
collection? an instance of chandler? all chandler instances? if
they're actually globally unique (guids), then cosmo can be smart
about uuid references within sharing documents and actually set up
internal references between shared resources.

> 2. How do we support sending only diffs, including attribute
> deletions? Asked another way, do the bodies that we send to and from
> the server contain "verbs" ("add" this new item, "delete" this item",
> "set" this attribute value, "remove" this attribute value), or does
> the mere presence (and disappearance) of a resource on the server
> indicate creation (and deletion) of items, and does the lack of an
> attribute value in the resource body indicate removal of the attribute?

the latter approach suggests a more complicated change detection
algorithm, but i'm not sure if that's really true. i think i'd need to
put my hands on some actual code for each propoal to get any closer to
answering this question.

> 3. Do we want to include info about who made a change (and when)?
> What granularity?  Item level, or attribute?  This question is mostly
> directed at the design team.

i think we probably should assume that someday some featuree will need
this info.

> 4. How do we represent item deletions (tombstones)?

probably just a placeholder with a uuid:
<tombstone><uuid>1234</uuid></tombstone>

> 5. Do we want to use XML?  I assume yes, but just wanted to know if
> anyone is opposed.

i'd probably prefer xml, just because my environment provides
sophisticated xml processing tools.