[Cosmo-dev] Interesting idea to avoid EIM conflicts
Brian Moseley
bcm at osafoundation.org
Fri Mar 2 11:54:46 PST 2007
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.
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?
what do you expect the server to send for subs and syncs? would you
ever expect the server to send a deleted record?
More information about the cosmo-dev
mailing list