are you planning on implementing a JSON input reader as well?
On 10/07/2006, at 7:28 AM, Yonik Seeley wrote:
I'm 75% done implementing a JSON output writer. Here is a hand-typed example of the output: { "header":{"QTime":3} "qresult": {"numFound":16000, "start":0, "maxScore":12.53 "docs":[ {"foo":124, "bar":"wow", "score":1.414},{"foo":555, "bar":"dude", "mydate":"2006-07-07T23:59:59Z", score":2.135"},{"foo":777, "my_multivalued_field":[123,555,663], "score":.0943} ] } } A couple of notes: - there isn't explicit type info like there is in the XML... this should be OK, as most apps know what the types of fields are... if they don't, they can always fall back to using XML. - keys can't be repeated in a NamedList: In XML you could have <lst><int name="foo">5</int><int name="foo">10</int></lst> This will be writen out in JSON as {"foo":5, "foo 1":10}. - Order won't be maintained in a NamedList. Solr will maintain order when serializing to JSON, but most client sides will ignore that ordering (only arrays are ordered). This isn't a problem for normal result sets, but could be a problem for custom data for faceted browsing for instance. Highlighting: With the proposed highlighting format (still in JIRA), one would not be able to access highlighting info by position, but would have to rely on matching unique-id. Other potential issues: would it be useful to be able to change the serialized format so that something like Ruby could do a direct eval() like JavaScript can? Might also want to have an option to use python unicode strings also ( u'my unicode string' ) Comments, suggestions, criticisms? -Yonik
