lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Namespaces in response (SOLR-1586)
Date Fri, 11 Dec 2009 21:57:27 GMT
Hi Hoss,

> : 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.
> 
> it's a damned-if-you-do/damned-if-you-don't situation though ... you look
> at as "insulating" the response writers because all of the logic about
> serializing data is in the FieldType, but i look at it as "poluting" the
> FieldType with knowledge about the output formats -- there's a reason we
> didn't add "writeBinary" to the FieldTYpe when the BinaryResponseWriter
> was added ... the toObject abstraction let's the FieldType do whatever it
> wants internally, and provide it's "best face" to the world when asked.
> the ResponseWriters can then apply hueristics to decide the most
> compatible type they know of to use when representing it: "is it something
> complex i have a codec for? no; oh well, then is it soemthing that
> implemnets COllection? no; oh well, then is it something that is an
> instanceof Number? no; oh well, as a last resort we can stringify"

Sure, it's just that it's half-way on both sides right now like you said.
There's probably a middle ground. I like the "insulation" but I also
understand the "clutter" (i.e., what you're saying).

> 
> : 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.
> 
> I'm sure if we look hard enough at teh existing internal APIs, we can find
> a way to generate completley broken XML that no DOM, SAX or pull parser
> could possibly deal with cleanly -- but that doesn't mean we should do
> that just because it would allow us to start outputing a bunch of metadata
> that we think is useful.  breaking the (implicit) XML Schema is just as
> bad as breaking the XML itself.

Agreed. Let's document that (implicit) schema so loud people like me don't
keep bugging you guys when it's so obvious to you. I'm just trying to help.
I'll take an action.

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/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Mime
View raw message