[Nepomuk] Nepomuk - Moving away from Strigi

Vishesh Handa me at vhanda.in
Mon Oct 8 20:01:37 UTC 2012


On Tue, Oct 9, 2012 at 1:24 AM, John Layt <jlayt at kde.org> wrote:

> 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?
>

You would only need to compile the plugin and install it.

I was not terribly clear earlier, my fault. I was thinking from a technical
(developer) point of view. I thought it was understood that we would not
have a hard dependency to ffmpeg. When I said NepomukCore depends on
ffmpeg, I mean that the top level CmakeLists has the checks. That is all.

The plugin system is exactly as any other plugin based system in KDE.

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?
>

Well, we're somewhere in the middle right now. We were just discussing this
on #kde-devel.

Nepomuk will no longer depend on Strigi, but KFileMetaInfo still uses
strigi. So we either keep that functionality or decide how we want to
proceed. The new plugin based system has a hard link time dependency to
Nepomuk-Core, so it cannot go into kdelibs. I'm not sure what we want to do.


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



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121009/dc41ce19/attachment.html>


More information about the Nepomuk mailing list