Strigi splitting? was Re: Proposal: Integration of libKMetaData into kdelibs

[Jos van den Oever]

2006/12/18, Aaron J. Seigo <aseigo at kde.org>:
> > functionality are interesting for more than just desktop search as
> > I've shown with the stream-based kioslave for reading embedded files.
> > Some of you might think requiring all of Strigi for KDE4 might be a
> > bit much. So I'd like to discuss splitting it up in 2 or 3 parts.
> > Keeping all of it in one folder and simply using the compile time
> > options for disabling parts as desired is however a valid option too.
>
> what is your recommendation? you've done a great job of describing what we
> could do; i'm also interested in hearing what you think we should do.
There are two considerations that are important:
- Strigi as one package is nice for maintenance and releases. It
allows me to keep the various parts well matched to each others.
Notably streamindexer changed prompt changes in the daemon and the
backends. Currently the desire to have more finegrained control over
the extraction process will lead to additions to the
IndexerConfiguration class will happen.
- Removing the daemon from the main package will help other desktop
search projects might adapt to using streamindexer for data
extraction. This is mainly a political thing. This can also be
resolved by packaging that code separately but keeping it together in
SVN.

So moving Strigi to /trunk/kdesupport/strigi and adding a script
packagestrigilibs.sh is probably the best option.

>
> > == libstreamindexer ==
> > part of Strigi could be used as a KFileMetaInfo replacement. It would
> > allow nifty things like extracting metadata while a file is
> > downloading for any supported filetype. This would require porting of
> > the current metadata extractors from KDE.
>
> bring it on! porting the metadata extractors shouldn't be all that much work
> compared to the benefits. a couple of "KFMI porting" days should probably do
> it. we'll also need to write a little HOWTO to do the porting for 3rd
> parties.
>
> sounds like a good tutorial for the developer wiki. *hint* ;)

Hint noted!