jstreams and strigi for KFileMetaInfo

[Aaron J. Seigo]

On Wednesday 27 September 2006 13:01, Krzysztof Lichota wrote:
> What you propose is KDE->Strigi->Strigi backends.
> I propose KDE->Strigi KDE plugin->Strigi backends.
> This way if using Strigi is not feasible, we can replace it with plugin
> for direct reading or plugin for superduper filesystem. More flexibility :)

strigi can have a backend for SuperDuperFS as well. which is to say 
strigi -is- the plugin system. the risk here is relying on strigi, and that's 
only a risk because it's something we don't do now. i strongly suggest we tie 
into strigi as it seems to be Ready Enough at this point and if we rely on 
it, we'll pound on it and if we pound on it it'll mature even faster.

van dan Oever is doing really good work with it and we certainly need 
something just like it.

remember as well, that with strigi we can well end up with better sources of 
metadata than plugins that read off of files on disk such as applications 
that process data that appear as files (think email) or stream handlers that 
can look inside of files on disk an analyze discreet chunks of data within 
(think archive files).

-- 
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/031905d2/attachment.sig>