[zeromq-dev] The CAP theorem: A taxonomy for 0MQ sockets, devices, patterns and best practices?
Mark V
mvyver at gmail.com
Thu Aug 12 08:50:15 CEST 2010
Hi,
These thoughts arose while reading the draft of the User Guide (2010.08.12):
I wonder if it doesn't make sense to consistently describe 0MQ, its
sockets, its devices, patterns and best practices in terms of the CAP
theorem?
A link to an 'appropriate' definition could be provided in the 'Basic
Concepts' section of the user guide - unless use of 0MQ implies
special definitions of the C, A and P. In which case that should be
made explicit sooner rather than later.
To my mind, this emphasizes the 'internet scale' that the cool/big
kids are interested in, and provides a systematic structure to all
topic and example discussions, i.e. perhaps example discussions could
address the C, the A and the P inherent in each example.
Perhaps a convention might emerge by which the inherent CAP theorem
trade-offs are always discussed?
Anyway, the user guide would seem to be a natural place to introduce a
discussion of:
- Whether all 0MQ sockets are CAP agnostic, i.e. is no choice ruled
out by using a particular socket type?
- Whether the std 0MQ devices are CAP agnostic, i.e. are equally
suited to any pair of CAP?
- Which of the 'typical patterns' are better suited to C+P, which
A+P? etc. e.g For C+P, then in example/pattern X partitioning is more
efficient than in example/pattern Y, where consistency is more
efficient.
The CAP objectives and trade-offs might eventually be a useful
taxonomy for describing 0MQ patterns and best practices?
If so, making this explicit from the get-go may help people focus on
the trade-offs important in their use cases, and how 0MQ can minimize
the implementation pain while maximizing the benefits available from
0MQ.
As the number of devices, patterns and techniques developed expands it
might also allow people to drill down to just the topics/discussions
and examples that are relevant to their use cases.
HTH?
Mark
More information about the zeromq-dev
mailing list