I agree fully, for me the PHP client API in the works should be including a good set of unit tests.
The channel dilemma also shows up, as in the PHP ecosystem there are at least 2 major ones to hook up. Personally I would go for eZ components as this already provides a good framework with unit tests. But I also think having something generic (and supports PHP4.x) that makes its way into Solr client API's independently is good to increase the adoption of Solr anyhow. Just a few early monday morning thoughts ... Paul On 4/1/07, Jeff Rodenburg <[EMAIL PROTECTED]> wrote:
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 > >
