Re: [bailey-developers] lattice master

[Ning L. <nin...@gm...>]

On Thu, Feb 28, 2008 at 5:37 PM, Doug Cutting <cu...@ap...> wrote:
>  A unique updatetable index per document would be nice, but I'm not yet
>  entirely convinced it is practical.

Not if short glitches are not acceptable. In BigTable, a tablet is served
by a single tablet server. I wonder if they find it to be a problem.

>  I'd imagined each node periodically querying its neighbors for changes
>  in the range they share.  We shouldn't rely on clock synchronization, so
>  each node would keep the last revision of each neighbor that it has
>  sync'd with.  So, the first time they connect, they pass revision zero
>  and receive all updates for their overlap.  The next time they only need
>  to retrieve updates since the last.

This works...

>  Documents could also have an application-specified revision.  This would
>  greatly simplify reconciliation, since we could use these to resolve all
>  disputes in a predictable way: higher revision wins.

I like this.

>  Perhaps we'd want two formats for updates sent between nodes: outline
>  and full, where outline just contains a sequence of <{ADD|DEL}, id,
>  revision>.  Then the retrieving node can process these and determine
>  which revisions of which ids it needs, then retrieve those as a second step.

Perhaps just the full mode until we see a demand for the outline mode.

>  This approach is tolerant of network partitoning, and not too
>  complicated.  What do you think?

It seems good. I need to figure out completely the protocol when nodes
join and leave the system.

Ning