Thanks for the input, but on the desktop we really want a in-process search engine that runs in our desktop app's process space, so out-of-proc search engine like Solr wouldn't help.
-----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 8:42 AM To: [email protected] Subject: Re: Design of the Lucene framework: will it be .NET compliant? 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. >>
