Have a VectorClock prototype

[Raynos]

If we have a specific object for VectorClock we can implement .valueOf() to allow a < b to work.

We can also implement .toJSON() to return a compact format of the clock to send over the wire.

[mixu]

Thanks for the reminder! Not sure how valueOf() would work though, since a vector clock is basically a composite value that only defines a partial order e.g unrelated { a: 1} vs {b:1} and concurrent { a: 1, b: 2 } vs {a: 1, c: 1} values have no defined order but you can only say that when you see both objects. I mean the comparison is possible where you can say the values are one of a < b, b < a, a == b or a and b concurrent (not just a < b is true/false).

Based on the spec ( http://www.ecma-international.org/ecma-262/5.1/#sec-11.8.5 ) it seems the comparison would work for values with the same keys or where one is a prefix (assuming "a1" vs "a2" and "a1" vs "a1b1" or "a1" vs "a2"), but the result would be arbitrary/misleading (ascii) for values that don't have the same keys ("b1" vs "c2"). Any ideas?

[Raynos]

• (a < b) === true then a is earlier then b
• (a > b) === true then a is later then b
• (a === b) === true then a is concurrent with b

The situation where a is b can't be true. no two things happen at the same time, only concurrent things happen at the same time.

It should be simple to serialize a vectorclock to a number or string such that the above holds.

[mixu]

Hmm - I think the problem is that in order to distinguish between different vector clocks, we need to assign distinct values to them. If we do that, then an operator like < or > imposes a total order on the items since each is a separate integer (here, ASCII is just a different kind of integer value, not considering the prefix comparison part of the ECMA spec).

But since in a partial order, there is no defined order between two items that are causally unrelated, imposing a total order on the items results in some concurrent clocks being arbitrarily ordered.

In other words, because we assign distinct values to distinct clocks, some concurrent updates are considered to have happened either earlier than or later than each other when in the correct interpretation they should be considered concurrent (e.g ===). But if we assigned equal values to them, then we could not distinguish between the two clocks and hence their descendants would be considered to be causally related when in fact they might not be. Now, that might be possible to solve for some sets of vector clocks, but in order to do that we'd need a fixed set of vector clocks to ensure that the lack-of-ordering property is preserved without introducing errors in the descendants of those clocks. But valueOf can only look at a single vector clock, not the whole set, so avoiding the introduction of these kinds of errors seems to be infeasible.

In reducing the vector clock into a single number, the vector clocks are reduced to Lamport clocks - every two pairs of events can be ordered - so we lose information about the fact that two events are not causally related.