an eddy in the bitstream
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:
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.
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.
© 2025 peknet
Theme by Anders Noren — Up ↑