why a separate gem? about rsolr-json HOT 6 OPEN

There's something nice about rsolr being extremely lean and hardly pulling in any external dependencies. That said, I'm all for it (and, wrote this code to be pretty easy to copy over, I hope), but I don't know if we even want to use json by default, or exclusively, etc.

from rsolr-json.

I also like the idea of rsolr staying super lean, but I sympathize with jrochkind's concern about the cognitive overhead.

Why though do we want JSON in a Ruby client? I'd think that Ruby would be more performant. Maybe you want to render JSON but don't want the overhead of de-re-serializing?

On a related note... I did consider setting the "wt" param to xml once so that ordered datums (facet_counts) would be indeed, ordered. I wish Solr's json/ruby response writers would return array's of tuples for those types of things and not hash-maps.

from rsolr-json.

There was recently a discussion on the blacklight listserv where some people had some reasons for preferring JSON.

Here's the listserv discussion

I left it thinking json communication between Solr and Blacklight was certainly a reasonable option for someone want, and prob meant sense as an option. I guess cbeer did too, hence this?

from rsolr-json.

Oh, I see now. Thanks for the link/reference. That eval always bothered me
too.

• Matt

On Tue, Jan 21, 2014 at 11:38 PM, Jonathan Rochkind <
[email protected]> wrote:

There was recently a discussion on the blacklight listserv where some
people had some reasons for preferring JSON.

Here's the listserv discussionhttps://groups.google.com/forum/#!searchin/blacklight-development/solr%2420json%2420response/blacklight-development/z2mvSWwNXPE/-Dtc4WtKoLgJ

I left it thinking json communication between Solr and Blacklight was
certainly a reasonable option for someone want, and prob meant sense as an
option. I guess cbeer did too, hence this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-32992975
.

from rsolr-json.

@mwmitchell : On a related note... I did consider setting the "wt" param to xml once so that ordered datums (facet_counts) would be indeed, ordered. I wish Solr's json/ruby response writers would return array's of tuples for those types of things and not hash-maps.

Check out [json.nl](http://wiki.apache.org/solr/SolJSON) (although, now that ruby hashes are ordered, maybe it's a moot point?)

from rsolr-json.

Ruby hashes are now ordered? w00t! Maybe that solves all the issues. Long ago I had given some thought to making Solr's Ruby response be smarter about types. See https://issues.apache.org/jira/browse/SOLR-358

from rsolr-json.