[Cosmo-dev] Interesting idea to avoid EIM conflicts

[Morgen Sagen]

On Mar 2, 2007, at 11:54 AM, Brian Moseley wrote:
> On 2/15/07, Morgen Sagen <morgen at osafoundation.org> wrote:
>
>> Again, the idea is that whenever we want EIM fields that will  
>> *never* result
>> in conflict, we define a new record type for where all fields in  
>> the record
>> are keys.  Thus a record never actually *changes*, only created  
>> and deleted.
>>  We're including lastModified (time) as a field in this record as  
>> well so
>> that we can ignore out-of-date records.  Encoding this behavior  
>> into the
>> schema in this manner means that when some plug-in developer  
>> defines their
>> own item types and sharing schema, and they need the same behavior  
>> for one
>> of their fields, we don't have to modify our EIM-handling code at  
>> all -- it
>> will just work.
>
> coming back to this after a couple weeks, i'm a bit confused about how
> it's meant to work.

The paragraph describing Chandler's implementation of it pretty much  
sums up the desired behavior:

On 2/15/07, Morgen Sagen wrote:
> FYI, the way Chandler handles this is we keep the EIM records  
> around for the last-agreed upon shared state of an item (plus the  
> EIM records representing pending conflicts).  When it's time to  
> send a locally-changed item to the server, we generate the EIM  
> records for the current state of the item and compare those against  
> the previously synced state.  If the item has generated a new  
> lastModifiedBy record, the diffing machinery will automatically see  
> that it needs to send a "deletion" record for the old  
> lastModifiedBy record.  For the inbound direction, if we receive a  
> lastModifiedBy record from the server, we will only apply it to the  
> item if its lastModified (time) field is more recent than what the  
> item already has.

On Mar 2, 2007, at 11:54 AM, Brian Moseley wrote:
> what is your expectation of how the server applies these records? what
> is the server meant to do when it gets one of these records in a
> publish or update? what is the meaning to the server of a deleted
> record?

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.

> what do you expect the server to send for subs and syncs? would you
> ever expect the server to send a deleted record?

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.