jstreams and strigi for KFileMetaInfo

[Krzysztof Lichota]

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 :)

	Krzysztof Lichota


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060928/e160be5f/attachment.sig>