[Cosmo-dev] morse code docs

[Brian Moseley]

On 11/13/06, Randy Letness <randy at osafoundation.org> wrote:

> 1. "Delete Signifies that the indicated collection and all contained
> items are to be removed immediately from storage"
> If we decide to use tombstones, this won't be the case.  Is this OK?

right, i forgot about that. i'll update the spec when we have a plan
for deleted items.

> 2. If we have to support locking, then we need to decide if we are going
> to support distributed locking (load-balanced cosmo), which is a lot
> more work.  Maybe for 0.6 we just support single server cosmo and tackle
> multiple server cosmo in 0.7 or later.

let's talk about this in more detail, perhaps in a new thread. ideally
locking would be database state rather than server state (which we're
trying to not have), but you're right that we probably don't need that
until preview.

> 3. I touched on this on a previous email to you, but we need to figure
> out what happens when another client updates between a sync/update from
> the current client.  The use case is:
>
> Client B does sync
> Client A does sync
> Client B does update
> Client A does update
>
> How does Client A get B's changes?
>
> You mentioned we could require the sync token for an update, and the
> server would return an error if the token doesn't match up with the last
> sync, as in this case.  Client A would then be required to do another
> sync to get the updates from Client B, before sending its own updates.
> So this would end up looking like:
>
> Client A does sync
> Client B does update
> Client A does update (gets error)
> Client A does sync
> Client A does update (no error)

does this sound good to everyone else?