Sure, Solr is Java... but its a server process just like your
database server or any other service you rely on in which its
implementation language is irrelevant to your needs. Yes, it
requires a JVM, but other than that you can drop it in and use it.
Erik
On Mar 12, 2007, at 6:15 AM, Jokin Cuadrado wrote:
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.
