Another good question, and the answer is "it depends". As a guiding
principle for the expectations of this abstraction, convergence should
yield a collection as if it had all of the operations applied to it in the
order that they were applied, locally. So let's work with M, and nodes A
and B.
Alex, yeah that explains it for me. I'll probably want to use a fully
connected address space, via a mesh or a hub and spoke topology, that I
fully manage - so this is the perfect level of abstraction for me. I'd like
to see that ZQ implementation though.
So, to be clear, if node A sends schism-ma
I'll try to answer this question and John's at the same time.
Schism does not try to manage state for you over time; there are a lot of
good tools for doing that already (atoms, refs, agents, channels, etc).
Schism is a set of collections that augment basic clojure collections with
enough addit
This is cool!
There seems to be some room for a recommendation on how to apply these data
structures effectively in practice, especially around the distribution
mechanism. For instance, I can imagine storing these in an atom and using
watchers to push changes out over zero-mq. Or is that the
Wow, this is really cool!
Could you describe how one might go about using this to implement, say, a
crdt chat room using maps and sets? Can I for instance just push crdts
between clients in a serverless fashion?
Perhaps some examples would be instructive, but I've been hoping for
something just l
Good evening!
I submit for your evaluation and reasoned feedback a library I've been
working on to provide a set of convergent replicated data types to Clojure
and ClojureScript:
https://github.com/aredington/schism
[com.holychao/schism "0.1.0"]
Schism provides convergent collections for sets,
