Nepomuk as hard dependency in future?

[Volker Krause]

On Tuesday 20 October 2009 13:28:55 Michael Jansen wrote:
> > Making Nepomuk integration optional is quite difficult once you start to
> > depend on it for essential features of your application though. And at
> >  least for KDE PIM, I expect that to happen. In fact, distibution list
> >  resolution already depends on it in some cases.
> >
> > > > but it should be available everywhere our apps travel.
> > >
> > > This is much easier than trying to integrate with native search.
>
> But having to indexing daemon? People already compain about having one of
> them eating up their resources.
>
> Perhaps we could get a two fold strategy. Bring in nepomuk for all the
> semantic features that do not require (strigi?) the indexing demon like
> tagging, rating etc.
>
> And than have a look if we could just hide the indexing part under a layer.
>
> Or am i wrong and nepomuk does not include the indexing part by default?

I'm not sure about the default, but file indexing is independent of the actual 
Nepomuk functionality and can be disabled separately (systemsettings -> 
advanced -> desktop search). And the initial file indexing is indeed what 
gives Nepomuk/Strigi/$SEARCHSERVICE its bad reputation regarding resource 
consumption. I expect we will see the same for the intial indexing of the 
data stored in Akonadi.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091020/d7587dd4/attachment.sig>