Remove multi_json and replace with stdlib json

[weynsee]

With multi_json's future being a little murky and the standard lib json (in 1.9) performing much faster than multi_json, it might be time to remove the dependency on multi_json.

If there's interest in this I can submit a PR for this.

[weynsee]

For 1.8 users, they would have to use the json gem.

[karmi]

Let's first wait and see how MultiJson future will pan out. As noted in the original issue, MultiJson allows everybody to use their preferred library without changing the interface -- without an abstraction like that, Tire would have to provide something like this on its own.

[weynsee]

Sounds good. Do you want to close this issue or keep it open for now?

[phoet]

👍 for this. we only had trouble using MultiJson anyways. always had to do a lot of monkey-patching for MultiJson and tire...

[karmi]

@phoet That's surprising -- would you be able to dig out some concrete issue/backtraces/whatever? I've never had any problem. That said, adding an abstraction for handling JSON is technically trivial, just laborious. I'd like to wait a bit and see -- I've seen these kind of problems being solved simply by waiting until dust settles.

[phoet]

@karmi remember all those rails json loading, symbolizing keys issues?

after that we switched to OJ as a json parser (really fast, reduced our response-times by half) and MultiJson was overriding all default OJ settings, so that we had to patch it to use our default settings. this seems to be resolved right now.

another thing was our dependency to couch_potato, which does not use MultiJson, so we basically had 2 JSON config points etc...

[phoet]

a little offside, but are there any plans to drop 1.8.7 support?

[karmi]

Definitely not on current Tire .)

[karmi]

after that we switched to OJ as a json parser (really fast, reduced our response-times by half)

Yeah, saw the performance implications in the linked issue and I'm definitely not happy about it. Still, we need to somehow make the JSON lib pluggable, which should be the sole responsibility and reason for MultiJson. Hopefully the situation will improve. I still believe abstractions a la MultiJson and Faraday are quite useful, since as a library author, you don't have to provide extension points yourself.

another thing was our dependency to couch_potato, which does not use MultiJson, so we basically had 2 JSON config points etc...

Ah, yeah, that sounds really painful...

[karmi]

Seems like https://github.com/intridea/multi_json is live and kicking?

For the record, https://github.com/elasticsearch/elasticsearch-ruby uses MultiJson and so far no issues have been reported. elasticsearch-ruby has modular serializer though, so you can pass whatever JSON library, including custom wrappers to it: http://rubydoc.info/gems/elasticsearch-transport/#Serializer_Implementations

Closing this?

[phoet]

👍