lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Rodenburg" <jeff.rodenb...@gmail.com>
Subject Re: C# API for Solr
Date Sun, 01 Apr 2007 16:22:12 GMT
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 <hossman_lucene@fucit.org> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message