[Cosmo-dev] Interesting idea to avoid EIM conflicts

[Morgen Sagen]

On Mar 2, 2007, at 1:48 PM, Brian Moseley wrote:

> 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.

Nah, Cosmo can ignore the deletion, and conditionally apply the non- 
deletion (based on lastModified timestamp)

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

It will usually send one of each.  But again, you can ignore the  
deletion.

>
>> 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.

I think we're okay here.  If the lastModifiedBy or lastModified  
changes, you'll emit a lastModifiedBy record (which includes both  
those fields along with the UUID).