The discussion of THRIFT-395 reminded me of another long ago issue that cropped up around the "string/binary" problem: the fact that binary is not a full-fledged type has some odd implications on legal representations in protocol implementations.
In particular, this places an odd restriction on readBinary() -- it MUST succeed if called on a string value as well as on a binary value. This can happen when skip() is called on a string value. I encountered this issue when writing the JSON protocol, which uses different protocol encoding for 'string' (standard JSON strings) and 'binary' (Base64 encoded). At one point, we had made an agreement that at some point when there was a break in backwards compatibility we would make the binary type into a full-fledged type of its own. Thought I'd just raise the issue again... Any chance this old wart will get fixed for the 0.1 release? If we aren't going to fix this, then, at the very least, we should make sure that this is well-documented somewhere for other protocol implementers. Chad
