Sounds like Lucy is not the right fit for you. Besides CLucene, you might also check out Hyperestraier: http://fallabs.com/hyperestraier/index.html
Depending on your needs, the full-text search in SQLite might work too: http://sqlite.org/fts3.html --nate On Sat, Nov 24, 2012 at 10:13 PM, Rayne Olivetti <[email protected]> wrote: > The reason for me to seek a C/C++ alternative for Lucene very simple: > performance (especially memory) and dependencies (no Java on many embedded > systems). > > This sounds like problem you need to solve anyway first, if you want people > to write bindings for other languages. > Unless there is a complete C API, I personally would rather stick to swig > bindings of clucene. > > And it behooves me to say that Lucy is trying to solve other problems (a > toy-swig project which you expect people to learn to use in order to wrap > your one, single library) that it's rather supposed to solve in the first > place. > Here's an excerpt from Lucy FAQ: > > Why don't you use Swig? > A major design goal of Lucy is to present bindings which are as idiomatic as > possible so that our users feel as though they are programming in their > native language and not in C. Swig is a great tool, but it does not offer > support for many of the features which make Lucy so user friendly: > subclassing, named parameters, default argument values, etc. > These excuses downright wrong. Surely SWIG handles inheritance, default > arguments, and named parameters (docstring features for python) for languages > that support them. If your favorite, killer feature X is missing for your > apparently-favorite-language Perl, why don't you just send a patch to Swig > instead of re-inventing the wheel? And I should and add Swig is a BIG wheel. > And mind you, not many languages support those features. > > And okay, I get that you love Perl, and you probably don't want to dig into > the giant called Swig just to implement a single feature you like. But please > understand that Perl is obsolete to many people today, and by not > implementing a complete C API, you're not letting people to use Swig (or > whatever tool the language X supports for wrapping C code) at their option. > > Last but not least, "loose C port" implies it can be used via C, which led me > to this project. In it's current form, Lucy mainly looks like a Perl port of > Lucene, boosted with some C code. > > Lucy is a project at it's infancy, so I expect many things to change in the > future. > But for now, I'm going with clucene+swig. > > > ----- Original Message ----- > From: Nathan Kurz <[email protected]> > To: [email protected]; Rayne Olivetti <[email protected]> > Cc: > Sent: Friday, November 23, 2012 2:33 AM > Subject: Re: [lucy-user] Using Lucy directly from C > > On Thu, Nov 22, 2012 at 4:35 AM, Rayne Olivetti <[email protected]> > wrote: >> I'm well aware of the purpose of Lucy, but is it not possible to use it >> directly from C? I can't find any documents regarding this, and the INSTALL >> file says "Currently it is available via Perl bindings.", which almost >> suggests "you're on your own if you're going to use Lucy from C" (and this >> sounds quite awkward for a C library). >> >> I'm also trying to write Go bindings (which is normally done via cgo, which >> allows Go code to directly call C functions), and using cgo doesn't require >> any of the binding magics that ships with Lucy --it works best with a plain, >> old C API. > > There is not yet a published C API. There is a strong desire to have > one, but it's yet to be a top priority. It will probably stay that > way until someone shows up on the mailing list with a clear need and > the willingness and ability to help work on it. :) > > The difficulty is that host languages are integral to the way Lucy > works, and some small but crucial pieces are implemented only in the > host language. There's been considerable interest in other languages, > but right now Perl is the only one fully supported. > > Here's a little more background: > http://lucene.472066.n3.nabble.com/Release-date-and-language-bindings-td676033.html > > --nate
