OK, this simplifies things greatly. For C#, the proper culture setting for interaction with Solr should be Invariant.
Basically, the primary requirement for Solrsharp is to be "culturally-consistent" with the targeted Solr server to ensure proper data-type formatting. Since Solr is culturally-agnostic, Solrsharp should be so as well. Thanks for the clarification. On 10/17/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > > : This is exactly the scenario. Ideally what I'd like to achieve is for > : Solrsharp to discover the culture settings from the targeted Solr > instance > : and set the client in appropriate position. > > well ... my point is there shouldn't be any cultural settings on the > "targeted" Solr server that the client needs to know about. > > the communication between the server and any clients should always be in a > fixed format independent of culture. Any (hypothetical) culture specific > settings the server has to have might affect teh functionality, but > shouldn't affect the communication (ie: for the purposes of date > rounding/faceting the Solr server might be configured to know what > timezone to use for rounding to the nearest day is, or what Locale to use > to compute the first first day of the week, but when returning that info > to clients it should still be stringified in an abolute format (UTC) : multi-lingual systems across different JVM and OS platforms. If it *were* > : the case that different underlying system stacks affected solr in such a > : way, Solrsharp should follow the server's lead. > > if that were the case, the server would be buggy and should be fixed :) > > i don't know much about C#, but i can't really think of a lot of cases > where client APIs really need to be very "multi-cultural" aware ... > typically culture/locale type settings related to parsing and formatting > of datatypes (ie: how to stringify a number, how to convert a date to/from > a string, etc...). when client code is taking input and sending it to > solr it's dealing with native objects nad stringifying them into the > "canonical" format Solr wants -- independent of culture. when client code > is reading data back from Solr and returning it it needs to parse those > strings from the canonical form and return them as native objects. > > The only "culture" that SolrSharp should need to worry about is the > InvariantCulture you described ... right? > > > > -Hoss > >
