lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Namespaces in response (SOLR-1586)
Date Fri, 11 Dec 2009 20:07:07 GMT

: > 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 an
: > 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.

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"

: 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.



-Hoss


Mime
View raw message