But solr currently is only for java, and as long as I understand they
want a solution that can be installed in both .net and java systems.
Maybe in their case, and as long as they develop in java, running
their search engine over the ikvm virtual machine would be a better
solution for maintainability if they want to target clients that have
a .net architecture
--
Jokin
On 3/12/07, Erik Hatcher <[EMAIL PROTECTED]> wrote:
James - have you researched whether Solr is a good fit for this
particular use case? Solr is quite amazing, and I strongly recommend
it for cases of cross-language needs.
Erik
On Mar 11, 2007, at 9:29 PM, Shaw, James wrote:
> I've posted the following comment in the blog but I think it's worth
> mentioning our company's use case of Lucene and our appreciation of
> API
> parity with Java Lucene:
>
> Hi, all,
> Just want to say that having parity with the Java API's does have its
> value, at least to our company. Our company is developing a portable
> search engine on top of Lucene that will work on both Java and .NET
> platforms. It's basically a wrapper around Lucene written in
> constrained
> Java that will be translated automatically by a Java to C# translator
> we've developed. If the Java and .NET versions of the API's differ too
> much then we will have to have an abstraction layer on top of the
> platform specific Lucene.
>
> The Java and .NET equivalence is very important to us and is the main
> reason we picked Lucene over other search engines for the the
> company-wide shared search component that's to be embedded in both our
> desktop and web applications, and while I know you can still keep
> functional parity with a different .NET API's (same index structure,
> same search results given the same query, etc), having the same
> API's as
> Java definitely makes writing our wrapper component a lot easier.
