It was extremely hard and much more complex to make it work with the streaming code.
Ah... I was coming from the perspective of a normal client that would say "deserialize this into an object hierarchy for me".
I think this is the crux of the confusion... I think you're coming at this from "how do I replace JSON with binary" in the streaming API.
Do you have a pointer into the streaming code that causes issues? I looked at SortingResponseWriter and it looks like it does the JSON encoding itself, so this patch won't affect that?
But , looking at JavabinCodec, it looks like a kitchen sink and it begs to be replaced with something saner.
This patch doesn't seem to do that though... (replace JavaBinCodec), it only adds to that complexity of the code.
I would like to know what is useful in using NamedList/SimpleOrderedmap/NamedList/SolrDocument compared to what JSON does today.
That seems like a different discussion... I already agreed "there is value to presenting standard containers only". This patch doesn't remove any of those things from the code base anyway. We're talking about the mechanism by which one can get standard java.util containers.
There is a lot of value in having a 1:1 mapping between binary/json
We just got done talking about the fact that it won't actually be a 1:1 mapping because binary can represent things that JSON can't. Round-tripping will fail.
And really, if we're looking at a new binary format, there are a lot of things I'd like to clean up...