[Nepomuk] Nepomuk - Moving away from Strigi

[Albert Astals Cid]

El Dilluns, 8 d'octubre de 2012, a les 20:54:03, John Layt va escriure:
> On 8 October 2012 14:51, Vishesh Handa <me at vhanda.in> wrote:
> > For 4.10, Nepomuk will no longer depend on Strigi for file indexing. We
> > have written our own file indexer which are based on popular libraries
> > such as taglib, exiv, ffmpeg, etc. This allows us to better control the
> > indexing process. If you would like to know more reasons as to why the
> > change was done, please read [1].
> > 
> > He suggested that the
> > file indexing plugins be present in a separate repository. It doesn't
> > affect us much, so I would like to know your opinion? Do you want it to
> > be in a separate repo?
> 
> Can we please keep this on-topic.  We may not like the idea, but the
> reality is our distro's have particular legal requirements that they
> need to meet before shipping code.  Some risks they are willing to
> take, others they are not, and that varies by distro.  This discussion
> is how best to help meet those requirements while still offering the
> maximum functionality to our users who want to add the plugins.
> 
> Vishesh tells us that he is using a plugin system and just wants to
> know if it needs a separate repo for the plugins.  Perhaps it would
> help if Vishesh provides more detail on how the the plugin system is
> structured and how it differs (if any) from the way Strigi currently
> does it (which is obviously already acceptable to the distros).  In
> particular is it possible to just install the extra plugins without a
> re-compile?
> 
> Taking the wider view, can you tell us how this affects the future of
> Stigi?  Would I be right in saying Strigi is no longer needed in KDE,
> i.e. is it deprecated, do the distro's need to install it any more,
> etc?

I had a discussion with Vishesh about this and we found out that KFileMetaInfo 
and friends use strigi and according to his initial plan they would still use 
it.

I complained that this would mean duplicity of code and could cause some 
consistency problems if there is an app that uses both KFileMetaInfo and the 
nepomuk way of getting metadata.

As far as I know Vishesh is trying to work out a solution for this, but it is 
probably not trivial given that kdelibs is frozen and thus doing big changes 
to KFileMetaInfo will be probably frowned upon.

Vishesh, do not hesitate to correct me if I did not summarize our discussion 
correctly.

Cheers,
  Albert

> 
> Cheers!
> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
> >> <<