What would make things consistent for the client api's is a prescribed set of implementations for a solr release. For example, executing searches with these parameters, support for facets requires those parameters, updates should be called in this manner, etc. For lack of a better term, a loosely-coupled interface definition. Those requirements could then be versioned, and the various api's could advertise themselves as solr 1.0compliant, solr 1.1 compliant, and so on. The solr release dictates the requirements for compliance; the api maintainer is responsible for meeting those requirements. This would also be handy when certain features are deprecated, i.e. when the /update url is changed.
Regarding C#, this would be easy enough to implement. There are common community methods for building/compilation, test libraries, and help documentation, so doing things consistently with Erik and the solrb library works for C# as well (and I assume most other languages.) -- j On 3/31/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
On a related note: We've still never really figured out how to deal with integrating compilation or testing for client code into our main and build system -- or for that matter how we should distribute them when we do our next release, so if you have any suggestions regarding your C# client by all means speak up ... in the mean time we can do the same thing Erik started with solrb and flare: an isolated build system that makes sense to the people who understand that language and rely on community to cacth any changes to Solr that might break clients. -Hoss
