Hi Hoss, On 12/14/09 3:18 PM, "Chris Hostetter" <hossman_luc...@fucit.org> wrote:
> > : 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()). Conceptually I think that the best approach would be to do something similar to the functionality of #toObject, but to not call it that. #toInternal and #toExternal are actually good names, their interface is just off (they shouldn't return Strings). > > : 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. You may be right, but actually quite a few issues have referenced even non XMLWriters of similar issues. See: http://issues.apache.org/jira/browse/SOLR-1616 http://issues.apache.org/jira/browse/SOLR-358 http://issues.apache.org/jira/browse/SOLR-1555 http://issues.apache.org/jira/browse/SOLR-431 http://issues.apache.org/jira/browse/SOLR-912 > > 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. Maybe, maybe not. I'm not sure the effect is to make it crystal clear as much as it is to make it "clearer". XMLWriter is totally ambiguous -- what type of "XML" does it generate? I would argue "SOLR response XML", hence the SorlXmlResponseWriter. > > : 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... > > https://issues.apache.org/jira/browse/SOLR-17 I commented on SOLR-17 on what could be done with it, and I linked it to the new issue I threw up: SOLR-1646. Both can be closed at the same time, or even better, I can close SOLR-1646 and then work diligently on trying to get SOLR-17 committed. Even for documentation purposes it's well worth while. > > > : 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). > > +1 > > 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. +1! Thanks, Hoss. 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
