I'm working on a C++ driver for the new binary protocol, and have one or two items of feedback/questions regarding the spec.

1. There are column types that correspond to types that are not defined by the spec such as Boolean, UUID, Timestamp, Decimal, Double, Float etc.. Will these types always a serialized java type? What happens if Java doesn't define a size or byte order? Are these defined in a cassandra doc somewhere?

2. This is more feedback then a question: [option] is an [int][string], except that the string only exists if [int] is 0x00 when returning rows from a query result. Will this logic always be true? If so can we move that logic up into the type definition so that we have a guarantee? If not then I'll need to implement two sets of deserialization logic, one for row results, one for everything else.

3. Right now global keyspace and global table flags are not being used in my test query results, this means that columns returned could possibly come from multiple tables. As a result the methods on my row class need parameters for keyspace, table, and column (cql_row_t::get_string(k, t, c)) for all cases, CQL currently lacks a join so there is no reason why the global flag wouldn't be set. Is this a bug? Also, the reference Java driver always assumes the same keyspace and table, which given that there is no join is correct, but is an incorrect implementation according to the spec.

For those that are interested:

It's asynchronous, but I plan on also offering synchronous functionality as well. It still needs connection pooling, retry, convenience deserialization methods on row, and event listening. I'm also back filling documentation and unit tests this week. I'm currently building on OSX, but it should build on windows, linux. It's only dependencies are boost asio, and boost system (a dep of asio). The build chain is cmake.

I plan on wrapping the library with N languages where N is defined by the community. I'm taking requests. Also, if you have any design criticisms come at me, I'de like to make any changes before I get much further.

Also, if someone has a preferred method of logging in C/C++ other than callback I'm all ears.

--Matt Stump