comparing BSON and tnetstring

[Ben Atkin]

I just found out about tnetstring through Zed Shaw and it sounds a lot like BSON. One difference is that it appears to only accept JSON types; that is, there is no date type and there's no binary type.

http://tnetstrings.org/

https://github.com/rfk/tnetstring

What do you folks think of this? Does it solve a big part of the problems with JSON that BSON was intended to solve? Is it simpler than BSON? Would BSON lose much if it adopted a format like this, with more than just the JSON types allowed for the type character? I'm asking this last question hypothetically.

Ben

[Ben Atkin]

I was wrong about the lack of a binary type...the string type doubles as a binary type.

4. Makes no assumptions about string contents and can store binary data without escaping or encoding them.

On further investigation the sizes are only used for tokenizing, not parsing: that means that in order for a streaming parser to skip over an object or an array all its descendants have to be skipped over individually. IIRC with BSON a streaming parser can skip over an entire object or array. How important is this functionality in practice?

Ben

[Dwight Merriman]

if your objects are big with lots of embedding, it's important.  if they aren't, it probably isn't so critical.

[Mathias Stearn]

An important difference is that the size field in BSON is binary while
it is ASCII in tnetstring. Based on our profiling we know that in many
cases the slowest part of BSON is making the ASCII indexes for arrays,
so much so that in the server we cache ASCII versions of the numbers 0
through 99. Therefore, I think there are likely to be serious
performance issues with tnetstring.