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

[Aaron J. Seigo]

On Monday 18 December 2006 14:12, Jos van den Oever wrote:
> Related to this, I'd like to move Strigi into something more mature
> than playground and add it as a dependency to KDE4, since parts of its

*applause*

> 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.

> == 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* ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061218/5beac80c/attachment.sig>