Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "Mattmann, Chris A (388J)" <chris.a.mattmann@jpl.nasa.gov>
To: "solr-dev@lucene.apache.org" <solr-dev@lucene.apache.org>
CC: "yonik@lucidimagination.com" <yonik@lucidimagination.com>
Date: Wed, 9 Dec 2009 11:27:51 -0800
Subject: Re: Namespaces in response (SOLR-1586)
Thread-Topic: Namespaces in response (SOLR-1586)
Thread-Index: Acp4/qFGe8L1f6g3T7SbcTI6Ra68VAABxE7r
Message-ID: <C7453A37.75EB%Chris.A.Mattmann@jpl.nasa.gov>
In-Reply-To: <Pine.LNX.4.64.0912091030520.16331@radix.cryptio.net>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Hoss,

> : ...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.  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 write=
rs
> : as a string, but some newer smarter response writer could output it in
> : some more sophisticated manner.
>=20
> The caveat to that, now that i've skimmed SOLR-1586, is that it currently
> only applies to objects "added" to the SolrQueryResponse (or one of hte
> containers in it) datastructure that the ResponseWriter's "walk"
> themselves ... because of the back-ass-wards way we have FieldTypes write
> their values directly to an XMLWriter or a TextWriter the idea of using a=
n
> object that stringifies itself as needed doesn't really apply very well

I think it's rather powerful. You insulate the following variations into 1
single place to change them (FieldType):

* output representation
* indexing
* validation

To remove this from FieldType would be to strew the same functionality
across multiple classes, which doesn't make sense IMHO.

> ... and it won't unless we switch all of the ResponseWRiters to follow th=
e
> BinaryResponseWriter model of using FieldType.toObject(...) to get the
> field value as an "obejct" that can be sent over the wire -- then the
> existing XmlResponseWriter, and the Text ResponseWriters, can call
> toString() on Objects they doesn't understand, and some
> newer/hipper/cooler response writers that understand georss can do fancie=
r
> things with it.

In the long run, this might be nice, and +1 on getting there in the long
run. In the short, a compromise is to allow namespacing on fields in the
existing XmlWriter, which is allowed anyways, whether by oversight or not.

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.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++