Re: C# API for Solr

[Chris Hostetter <ho...@fucit.org>]

: One administrative question: can I contribute these files to be stored under
: /lucene/solr/trunk/client?  I don't have a handy place for making these
: publicly accessible at the moment.

yeah, as long as you can submit them in a Jira issue and legally check the
"grant apache liscence" radio button (or whatever it says) then it can be
commited into the solr trunk.

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

Re: C# API for Solr

[Paul Borgermans <pa...@gmail.com>]

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 <je...@gmail.com> 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 <ho...@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
> >
> >
>

Re: C# API for Solr

[Jeff Rodenburg <je...@gmail.com>]

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 <ho...@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
>
>

Re: C# API for Solr

[Erik Hatcher <er...@ehatchersolutions.com>]

It would be great to have solr-ruby (the library formerly known as  
solrb) included with Solr distributions, as well as Flare too.  It  
would give these libraries visibility and usability they'd not see if  
they required additional downloads or "svn co".  I can certainly say  
that solr-ruby does not faithfully keep up with all the great stuff  
that keeps innovating in Solr but its quite usable as-is already and  
will get even more so when more folks experience it.

However, these client libraries often desire to release themselves  
through other channels, like pushing solr-ruby to RubyForge for easy  
installation with 'gem install solr-ruby'.

We could certainly have the solr-ruby Rakefile invoked from our  
Hudson build system to have all the unit tests run.  We have quite a  
robust set of tests in there actually.

	Erik


On Mar 31, 2007, at 9:41 PM, Chris Hostetter wrote:

>
> : One administrative question: can I contribute these files to be  
> stored under
> : /lucene/solr/trunk/client?  I don't have a handy place for making  
> these
> : publicly accessible at the moment.
>
> yeah, as long as you can submit them in a Jira issue and legally  
> check the
> "grant apache liscence" radio button (or whatever it says) then it  
> can be
> commited into the solr trunk.
>
> 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