You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Erik Hatcher <er...@gmail.com> on 2010/03/03 21:08:07 UTC
"Lucene" connector questions
I'm curious why the LuceneConnector doesn't use the SolrJ API?
Instead, there's a custom HttpPoster class that does a lot of work
that SolrJ already handles internally.
Also, this probably should be called a SolrConnector instead, eh?
Since it's writing to Solr, not to Lucene directly.
Thanks,
Erik
Re: "Lucene" connector questions
Posted by Karl Wright <kw...@metacarta.com>.
Grant Ingersoll wrote:
> A bigger question is, should LCF be responsible for this stuff or should Solr, etc. be responsible for it? For instance, perhaps all Solr needs is to implement a DataImportHandler processor?
>
Doesn't Solr also handle document conversions, pipeline, etc.?
Karl
>
> On Mar 3, 2010, at 1:19 PM, Karl Wright wrote:
>
>> Erik Hatcher wrote:
>>> I'm curious why the LuceneConnector doesn't use the SolrJ API? Instead, there's a custom HttpPoster class that does a lot of work that SolrJ already handles internally.
>>> Also, this probably should be called a SolrConnector instead, eh? Since it's writing to Solr, not to Lucene directly.
>>> Thanks,
>>> Erik
>> The two main reasons were as follows. First, it was not clear when initial research was done exactly what the licensing for SolrJ was. Second, it appears that Solr itself seemed more configurable than the SolrJ API permitted, as far as webapp names, paths, etc are concerned. I'm not quite sure why that is, or whether there's a way to similarly configure SolrJ. If those issues can be addressed, and if the SolrJ API does not *require* other Apache jars that are in conflict with those for other connectors (commons-httpclient 4.x, for instance), then it could likely be changed along the lines you are suggesting.
>>
>> A naming change is also fine with me.
>>
>> Karl
>
Re: "Lucene" connector questions
Posted by Grant Ingersoll <gs...@apache.org>.
A bigger question is, should LCF be responsible for this stuff or should Solr, etc. be responsible for it? For instance, perhaps all Solr needs is to implement a DataImportHandler processor?
On Mar 3, 2010, at 1:19 PM, Karl Wright wrote:
> Erik Hatcher wrote:
>> I'm curious why the LuceneConnector doesn't use the SolrJ API? Instead, there's a custom HttpPoster class that does a lot of work that SolrJ already handles internally.
>> Also, this probably should be called a SolrConnector instead, eh? Since it's writing to Solr, not to Lucene directly.
>> Thanks,
>> Erik
>
> The two main reasons were as follows. First, it was not clear when initial research was done exactly what the licensing for SolrJ was. Second, it appears that Solr itself seemed more configurable than the SolrJ API permitted, as far as webapp names, paths, etc are concerned. I'm not quite sure why that is, or whether there's a way to similarly configure SolrJ. If those issues can be addressed, and if the SolrJ API does not *require* other Apache jars that are in conflict with those for other connectors (commons-httpclient 4.x, for instance), then it could likely be changed along the lines you are suggesting.
>
> A naming change is also fine with me.
>
> Karl
Re: "Lucene" connector questions
Posted by Karl Wright <kw...@metacarta.com>.
Erik Hatcher wrote:
> I'm curious why the LuceneConnector doesn't use the SolrJ API? Instead,
> there's a custom HttpPoster class that does a lot of work that SolrJ
> already handles internally.
>
> Also, this probably should be called a SolrConnector instead, eh? Since
> it's writing to Solr, not to Lucene directly.
>
> Thanks,
> Erik
>
The two main reasons were as follows. First, it was not clear when initial research was done exactly what the licensing for
SolrJ was. Second, it appears that Solr itself seemed more configurable than the SolrJ API permitted, as far as webapp names,
paths, etc are concerned. I'm not quite sure why that is, or whether there's a way to similarly configure SolrJ. If those
issues can be addressed, and if the SolrJ API does not *require* other Apache jars that are in conflict with those for other
connectors (commons-httpclient 4.x, for instance), then it could likely be changed along the lines you are suggesting.
A naming change is also fine with me.
Karl