lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Namespaces in response (SOLR-1586)
Date Mon, 14 Dec 2009 23:18:01 GMT

: I'm conflicted here. In simple semantics, sure it's just an array of
: float/double numbers. A, if a string must be used a comma is probably OK, so
: long as it maps to some existing known approach to represent points. I've
: asked several times if there are examples. I can point to one that uses
: spaces to separate the coordinates in the point (georss). What others use
: comma? 

I have no opinion about the details ... space seperated string, comma 
seperated string, list of ints ... they are all the same to me.

As a layman, my limited knowledge of geo coordinates has a vague notion 
that comma is the seperated used when discussing latitude nad longitute, 
but i have no real knowledge of naything GIS related.  (i think i remember 
that KML uses comma, but KML also has some weird idea that longitude comes 
first because that's what the guys writing graphics rendering engines 
aparently like: y-axis first)

: Well, I actually would disagree. What's the point of #toInternal and
: #toExternal then, other than to convert from the external representation to
: an internal Lucene index representation, and then to do the opposite coming
: out of the index? 

that is what they are for -- but they deal purely in string 
representations of hte data itself -- they don't (and shouldn't) know/care 
wether the data is then being encapsulted in JSON, thrift, Avro, Solr XML, 
RSS, KML, etc....

The "String" limitation of toExternal is on of the reasons toObject was 
added (and the reason the BinaryResponseWRiter uses toObject()).

: class final which it once was). We should rename that to
: SolrXmlResponseWriter, but it's not really generic XML (as the name
: suggests), it's SOLR's custom (undocumented) XML schema, right? Also, since

Eh... i don't know that the name suggests that it can generate generic 
XML, it generates a (particular) one to one mapping from the 
SolrQueryResponse to XML .. just like the JSONResponseWriter generates a 
one to one mapping fromthe SolrQueryResponse to JSON, and ditoo for the 
ruby/php/python writers ... there an infinite number of possible 
XML/JSON/Ruby/PHP/Python/etc. structures that *could* be generated from 
a SolrQueryResponse, no one has ever accused any of those response writers 
of not being flexible enough to generate a *different* type of response in 
those formats.

And practicle speaking: slapping "Solr" in front of a response writer 
classname isn't going to make it crystal clear that it produces a "solr 
specific" type of "____".  It's oging to make people think it's the 
"Solr" implemntation of "____".  "Solr" is hte prefix of enough classnames 
that eyeballs are just going to gloss over it.

: suggests), it's SOLR's custom (undocumented) XML schema, right? Also, since
: it's undocumented, I'd be happy to throw it together for it's XML format.

we actaully went round and round on documenting it back in the early days 
.. frequently it was deemed "self documenting" enough for end users so not 
much effort was ever put into it.  there was a Jira issue to create and 
XSD, but even once we had one, no one really had any idea what to *do* 
with it...

: Would that also be welcomed? Then, we should develop an easy extension point
: mechanism for people who want to develop their own XML response writers and
: write their own clients (or leverage existing clients that understand that
: XML).


I think the crux of this would be XML based response writer similar to hte 
BinaryResponseWriter that can use a "codec" type system for outputing 
known types of objects, using FiledType.toOBject() to get field values.  
Then we just have to provide "default" codecs for all the types of objects 
we produce "out of the box", but people can customize with their own 
codecs if they want differnet representation.


View raw message