Comment by brasetvik

3 years ago

> Though to address the GP a bit, the problem of concurrent writers without a sequencer (like a database) is less common than you might think.

My point was that even if you have a single non-scaleout database with a single time source, a sequence or a timestamp or a combination of both isn't as reliable a sequencer as you might think, unless you have at most one writer.

Thus, I think a "standard" should encourage a cursor concept that can use something that may reliably provide _all_ changes. If you have a single writer, you have a pretty easy job implementing that, as a plain sequence would work. (A timestamp could still break on clock adjustments, though)

This pertains to the "data replication" part of the listed goals, where getting everything is more important than in e.g. a social media news feed style thing where chronological order may be tenable - or less consequential if an item is missed.

2 comments

brasetvik

Reply
toomim  3 years ago

> Thus, I think a "standard" should encourage a cursor concept that can use something that may reliably provide _all_ changes.

I think the Braid standard might support what you want: https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-b...

We don't call it a "cursor", but the idea is to encode whatever clock or versioning information you want as an arbitrary string, with the only general requirement that the string is unique to that version.

You can use this with Lamport clocks, Vector Clocks, Version Vectors, Wall Clocks, (Agentid+Sequence) pairs, SHA hashes, or even blockchain transactions.