Today the kazoo counter recipe stores the value using ascii encoding while the curator SharedCount recipe stores the value using a signed 4 byte representation in big Endian byte order. Therefore, if a java client using curator and a python client using kazoo need to work with the same counter they will receive type errors.
I would like to submit a pull request that allows the two clients to co-exist peacefully.
The idea is to add a flag to kazoo's counter recipe constructor that instructs it to read and store data the same way that curator does. This option will default to off so as not to affect any existing clients that do not need this functionality.
Kazoo supports both int and float; however, curator's SharedCount only supports int. Therefore, whenever support for curator is enabled kazoo will only allow int values.
Since python 2.7 is nearing its end of life, this change must be compatible with both python 2 and 3.
Today the kazoo counter recipe stores the value using ascii encoding while the curator SharedCount recipe stores the value using a signed 4 byte representation in big Endian byte order. Therefore, if a java client using curator and a python client using kazoo need to work with the same counter they will receive type errors.
I would like to submit a pull request that allows the two clients to co-exist peacefully.
The idea is to add a flag to kazoo's counter recipe constructor that instructs it to read and store data the same way that curator does. This option will default to off so as not to affect any existing clients that do not need this functionality.
Kazoo supports both int and float; however, curator's SharedCount only supports int. Therefore, whenever support for curator is enabled kazoo will only allow int values.
Since python 2.7 is nearing its end of life, this change must be compatible with both python 2 and 3.
Example use:
counter = zk.Counter("/curator", support_curator=True)counter += 2counter -= 1counter.value == 1counter.pre_value == 2counter.post_value == 1