[Cosmo-dev] Interesting idea to avoid EIM conflicts

[Brian Moseley]

sorry. i must be having a mental block. i seem to be finding this
whole notion very confusing, so i'm going to have to keep asking
questions until a light bulb goes off above my head.

On 3/2/07, Morgen Sagen <morgen at osafoundation.org> wrote:

> The server should apply them if the timestamp is newer than the
> item's current "last modified" timestamp.  If a client sends a
> deletion record, Cosmo just needs to be able to tell other clients
> that the record got deleted.

sounds like the server wants to respond to a deleted record by nulling
the lastModifedBy attribute and to a non-deleted record by setting the
attribute.

will the client ever send both a deleted record and a regular record,
or will it always just be one or the other?

> Cosmo should send the new record and a deletion of any old records.
> Remember, the records never change -- all fields are keys.  So the
> records are only ever created and deleted.  A "change" to last
> modified by is represented by a deletion of the old record and a
> creation of a new record.

red flag! the server does not track attribute-level changes. it only
knows if an item or a stamp has been created, modified or deleted, not
which specific attributes might have been modified. this is why cosmo
sends every attribute of a record, even if only one attribute has
changed.