Swish3 Status 19 April 2008

There's been quite a bit of activity in the last month.

• The C++ Xapian example now can search as well as index, and there are Perl equivalents using Search::Xapian checked into svn as well. The C++ code will read/write the swish.xml header; the Perl does not (yet).
• The meta/prop id unique check now uses a hash for quick look up.
• The test suite for libswish3 is totally restructured. Now using Perl's Test::Harness and added a slew of new meta/prop tests. Alongside that were additions to the NamedBuffer debugging output to print each substring in the buffer.
• Several new string-related utility functions for converting ints to strings and back. Also a new config hash for configration options that use a StringList instead of a simple string.
• Fixed some mem leaks in the example .c programs and added more info to the swish_lint usage() output (including reminders about the various SWISH_DEBUG* env var values).

There are still several parser features yet to be implemented to support the Swish-e 2.4 config options, but those will likely take a backseat to getting a working swish3 Perl script running with SWISH::Prog and SWISH::Prog::Xapian.

File under projects Sat Apr 19 22:42:14 CT 2008

Swish3 Status 30 March 2008

More progress with Swish3.

• There is now a swish_xapian.cpp C++ example for using libswish3 with a Xapian backend. All that is complete is the indexing portion; still TODO is the search part. Still, a significant thing that it was so easy to build a search engine.
• The swish.xml header format is complete and can now read/write the header file. Need to add that part to the swish_xapian.cpp example.
• Squashed some long-standing memory leaks when using the filehandle functions.

Little by little.

File under projects Sun Mar 30 22:03:48 CT 2008

Swish3 Status 2008-03-15

I've finally gotten back to Swish3 development after several months away. Hard to believe I've been working on this project for something close to 3 years now.

Lately I have been focusing on the following things:

Header file format

Because Swish3 will have multiple IR backends, it is important that there be a consistent index metadata file that describes the MetaNames, Properties, and tokenizing information, just like the Swish2 header does. Just as with the config file format, it makes sense to define the header file format as XML, since we already have a robust XML parser for free. To make it simple, I have defined the header file XML schema to be the same as the config file schema. In short, you configure Swish3 by creating a header file. The "real" header file will be more strict about explicitly naming all the expected attribute values, numbering the MetaName/Property ids, etc. But the idea is simple: a single XML schema.

I have written the code to read header/config file format and create a swish_Config object. There's also code for merging 2 swish_Config objects together, so that you can define a config file to override an existing header file.

Still TODO is the code for writing the header file.

The Perl bindings have been updated to reflect the new swish_Config API. This required a great deal of reworking and thinking about the Perl API. I had to rewrite things a few times to get a workable solution. The key Perl mantra is "objects on demand." I.e., do not define any Perl objects that wrap C pointers and try to keep them on the XS side. Instead, create all Perl objects "just in time" as part of the get_* method call. This makes reference counting much simpler.

MetaNames and PropertyNames

These now have their own C API with swish_MetaName and swish_Property structs. These relate directly to the header file format and swish_Config. There will end up being a separate PropertyName API for search results. I still think we're going to have to port the Swish2 PropertyNames storage/retrieval code to Swish3 and have a backend-indepedent index.prop file. The issue with this is going to be scaling. One other thought I've had is storing properties in a SQLite db. That route won't allow for presorted properties, but does have the advantage of being much more transparent and de-buggable.

SWISH::Prog

I have moved the SWISH::Prog svn tree to svn.swish-e.org from peknet.com. I also moved SWISH::Filter (and likely will eventually move SWISH::API::More and its cousins).

SWISH::Prog will form the framework for the Perl implementation of Swish3. I know there are some folks who don't like the idea of Swish3 being so Perl-centric. To that I can say only, tough luck. :)

Seriously though, my perspective is that there will be multiple Swish3 implementations. The one I am working on is in Perl using SWISH::Prog. There's nothing to stop someone from implementing one in C or C++ or Java or whatever. libswish3 provides the parsing/tokenizing piece missing from other IR projects, and it is a library for the very reason that implementing a Swish3 program should be language-neutral. If you can link against a C library, then you can write a Swish3 program. The header file API is well documented; the backend is supposed to be pluggable. It's all about the API.

I do intend to write a swish_xapian.cpp program eventually, showing how to implement a C++ Swish3 program with Xapian. That could be the fallback program if you really don't want to use Perl.

Documentation

I've stared a swish_intro.7 and swish_migration.7 set of docs. swish_intro will outline the aggregator/normalizer/analyzer/indexer/searcher philosophy and the outline of the libswish3 API. swish_migration will discuss differences in Swish2 vs Swish3 and how you can convert your config files and move to using Swish3.

File under projects Sat Mar 15 22:23:14 CT 2008

Xapian 1.0 Released

Announced this morning.

Now if only I could find time to finish the swishx Swish3 example program...

File under projects Fri May 18 09:00:48 CT 2007

Open Source Search Tools

I was answering an email tonight from the hyperestraier list about Xapian and Lucene and KinoSearch, and as I was googling around to find all the email threads I remembered being a part of on the topic, it was interesting to see intersections I hadn't remembered, like how the same people (like me) keep popping up around these tools.

There are some folks who just need to implement a search engine for their website/company/intranet. These are the sysadmin types who just need something that works so that they can move on to the next project.

Then there are folks working in the IR field itself who are trying to build the Next Big Search Thing, following in google tradition. Good luck to them. They'll need it.

Then there are folks like me, who are a little OCD over things like IR and search. I consider the developers of the projects I list above in that camp. It's a good camp to be in.

Open source search tools have come a long way and there is really some good momentum now in implementing multiple terabyte, high volume search projects using open source technology. I like working in IR at a time like this. Hopeful. Almost. :)

File under projects Fri May 11 20:56:58 CT 2007

Swish3 Original Email

Was looking back through my email related to Swish3 and found the original thread in which I describe the idea to the developer list.

The historian in me thought it would be good to preserve that link somewhere. And I notice that original post was over 18 months ago. A (relatively) long time.

File under projects Sat Apr 14 20:36:52 CT 2007

Tokenizing

Marvin's got some good remarks on Perl's UTF-8 regexp vis-a-vis tokenizing strings. His remarks are timely, as I have been spending/wasting time lately in libswish3's C tokenizing functions. My goal was to replace them with Perl regexp matching, but that may have been pre-mature given Marvin's remarks.

File under projects Thu Mar 15 21:18:11 CT 2007