jstreams and strigi for KFileMetaInfo
krzysiek at lichota.net
Thu Sep 28 12:49:22 BST 2006
Aaron J. Seigo napisał(a):
> 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.
You mean Strigi-jstreams or Strigi-index?
I do not have anything against using Strigi-jstreams, but forcing users
to use index (and thus database) seems overkill for me.
> van dan Oever is doing really good work with it and we certainly need
> something just like it.
I do not say it is bad piece of work, just that we should keep
flexibility for other backends as they appear :)
> 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).
Seems you are talking about Strigi-jstreams :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
More information about the kde-core-devel