Hi Hoss, > : I think the initial geosearch feature can start off with > : <str>10,20</str> for a point. > > +1.
Fundamentally, how is a string a point? > > The current XML format SOlr uses was designed to be extremely simple, very > JSON-esque, and easily parsable by *anyone* in any langauge, without > needing special knowledge of types . Whoah. I'm totally confused now. Why have FieldTypes then? When not just use Lucene? The use case for FieldTypes is _not_ just for indexing, or querying. It's also for representation? > It has been heavily advertised as > only containing a very small handful of tags, representing primitive types > (int, long, float, date, double, str) and basic collections (arr, lst, > doc) ... even if id neverh ad a formal shema/DTD. Which is leading to this confusion. Your argument is kind of weird too -- just because you never had or advertised a feature like this (which SOLR allowed for a while I think), why prevent it? Allowing namespaces does _not_ break anything. > adding new tags to that > -- name spaced or otherwise -- is a very VERY bad idea for clients who > have come to expect that they can use very simple parsing code to access > all the data. I disagree. I've got a number of projects here that could potentially use this across multiple domains (planetary science, cancer research, earth science, space science, etc.) and they all need this capability. Also what's "simple" have to do with anything? Even "simple" parsers will parse what SOLR-1586 outputs. > > introducing a new 'point" concept, wether as <point> or as > <georss:point/>, is going to break things for people. Show me an example, I fundamentally disagree with this. > > As discussed with Mattman in another thread -- some public methods in > XMLWriter have inadvertantly made it possible for plugin writers to add > their own XML tags -- but that doesn't mean we should do it in the core > Solr distribution. And why is that? Isn't the point of SOLR to expand to use cases brought up by users of the system? As long as those use cases can be principally supported, without breaking backwards compatibility (or in that case, if they do, with large blinking red text that says it), then you're shutting people out for 0 benefit? It's aesthetics we're talking about here. > If you write your own custom XMLWriter you aren't > allowed to be suprised when it contains new tags, but our "out of hte box" > users shouldn't have to deal with such suprises. What surprise -- their code won't break? > > As also discussed in that same thread thread: it makes a lot of sense > in the long run to start having Response Writers that can generate more > "rich" XML based responses and if there are already well defined standards > for some of these concepts (like georss) then by all means we should > support them -- but the existing XmlResponseWriter should NOT start > generating new tags. I agree with this, but rather than waiting for that to come 2-3 months down the road, why not buy into the need for this now, with what exists? > > The contract for SolrQueryResponse has always said: > >>>>>> A SolrQueryResponse may contain the following types of Objects >>>>>> generated by the SolrRequestHandler that processed the request. >>>>>> ... >>>>>> Other data types may be added to the SolrQueryResponse, but there is >>>>>> no guarantee that QueryResponseWriters will be able to deal with >>>>>> unexpected types. > > ...unless things have changed since hte last time i looked, all of the > "out of the box" response writers call "toString()" on any object they > don't understand. Actually most of them call some variation of #toExternal, regardless, which returns a String. Also, #toInternal returns the same type, a String. > So the best way to move forward in a flexible manner > seems like it would be to add a new "GeoPoint" object to Solr, which > toStrings to a simple "-34.56,67.89" for use by existing response writers > as a string, but some newer smarter response writer could output it in > some more sophisticated manner. I'm not convinced of that. Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
