jstreams and strigi for KFileMetaInfo

[Aaron J. Seigo]

On Thursday 28 September 2006 10:56, Krzysztof Lichota wrote:
> I don't see advantages of hardcoding Strigi into KDE.
> Create API for metadata plugins, create open format for data exchange
> and let anyone plug in what he thinks works best for his needs.

if you wish to put a layer over strigi and introduce the concept of a "data 
source provider for metadata" with the possibility for more than one backend, 
that's fine. we still need to provide a default backend and we still need at 
least one backend. strigi seems to fit that need right now.

all i'm suggesting is that we remove the plugins from kfmi and instead put 
them into strigi and work with that as the (default) data source for us. the 
design and framework neutrality of strigi seems to offer advantages.

-- 
Aaron J. Seigo
Undulate Your Wantonness
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: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060928/e30dd4b3/attachment.sig>