[zeromq-dev] PUB-SUB filtering question
zee at technocore.ru
Tue Aug 17 12:05:42 CEST 2010
If I understand correctly you're the maintainer of the Java bindings, right?
We need proper binary prefixes at work, so I was going to change the
API to byte's anyway. I'll submit a pull request to you once I
finish it, but I've got a question.
Are there a lot of users of the API? Should I just remove the
setsockopt(long, String) methods and replace them with
setsockopt(long, byte) ones? Or leave the old ones for backwards
compatibility and mark them as deprecated?
On Mon, Aug 16, 2010 at 6:44 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:
>> Binary zero is representable in Java Strings, I've just been wrong
>> about the C API.
>> The problem is that Java Strings are currently converted to UTF-8 byte
>> sequences, which means that there is a whole set of possible prefixes
>> that can be used with C/Python/whatever API which would be impossible
>> to use from Java (as they would be impossible to encode as a String).
>> For example, any prefix starting with a byte larger than 0x80 would be
>> impossible to use from Java side.
>> Second, there's a bug in jzmq code. It's determining the prefix length
>> as "strlen (value)" (git 31a216ed1e98153ad0b526efa0d9aded24545b20,
>> Socket.cpp #223), which will lead to errors with zero-byte containing
> I agree with both points.
>> There are no such things as binary strings in Java. If 0MQ
>> topics/identities are supposed to be raw binary values (which,
>> according to Martin, they are), I think that using byte arrays is the
>> only sane option. The only downside is that developers will have to
>> convert the string to bytes manually, but that's a good thing - they
>> will have to be aware of character encodings and specify them in their
>> API docs and the API will be much more interoperable.
> Ok, I will look into changing the code to use byte; as I mentioned
> before, I have not dealt with this before, so feel free to jump in.
> Gonzalo Diethelm
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev