RFC: new strigi feature for nepomuk: indexer code as plugins.

Jos van den Oever jvdoever at gmail.com
Mon Oct 15 23:55:36 BST 2007


Hi all,

Strigi has always abstracted the index containing all the search
terms. This means you can use any database by implementing three
classes: IndexManager, IndexWriter and IndexReader. Only one thing was
missing: loading these index types from plugins. In practice this
meant that different indices need to be added at compile time. It also
meant no GPLed databases can be used.

For Nepomuk, Sebastian Trueg has written an implementation of a Strigi
index that stores the data in the Nepomuk storage. In doing so, he has
created a direct need for indexes as plugins.

So I've writting the code to make this possible and I've attached it
as a patch. Since we are in freeze I'm asking you all to have a look
at it. The plugin loading part is basically the same as what we use
for loading the analyzer plugins.

So what does the patch add:
- add a class IndexPluginLoader (not public) that looks in the strigi
plugin directory for files named strigiindex_$name.{so,dll} and loads
them if they define createIndexManager and deleteIndexManager.
- ports all strigi code to use it
- removes the compile-time lib${name]index.so libraries and uses the
plugins instead

No public API is changed by this code. It does add a macro
REGISTER_STRIGI_INDEXMANAGER for easily registering an IndexManager in
a plugin.

In hindsight, we should have added this much earlier as it makes (will
make) the build system dependencies much cleaner.

Is it ok to apply this patch?
Cheers,
Jos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strigiindexplugins.diff.gz
Type: application/x-gzip
Size: 8023 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071016/b620fb22/attachment.bin>


More information about the kde-core-devel mailing list