Nepomuk as hard dependency in future?

[Evgeny Egorochkin]

В сообщении от Вторник 20 октября 2009 02:49:51 автор Aaron J. Seigo написал:
> On October 19, 2009, Michael Jansen wrote:
> > iiuc. And i would not like to get nepomuk in gnome just by starting some
> >  kde app. I would prefer to use whatever gnome provides that is
> > equivalent.
> 
> ... which is?

Tracker and they are trying to implement Nepomuk too at this moment. So you 
can only avoid nepomuk-kde in gnome, but not nepomuk *evilgrin*

> (btw: http://trueg.wordpress.com/tag/gcds/ )
> 
> (a better example would've been windows or mac, btw, who both offer search
> frameworks of their own and have no realistic probability of ever working
>  with us on this in the near future)
> 
> if we're ok with no search or context features working outside of the KDE
> Workspace, hey, then great. "it works better in the KDE workspace" can
>  become the new mantra, but i don't think that's great for KDE
>  applications. search and context is increasingly not an optional feature.
>  that means we either give something to apps to use everywhere, or apps
>  will implement their own mojo and ignore what's in our frameworks.
> 
> maybe we could provide a wrapper lib like solid or phonon that would
>  provide search/context support in a "neutral" fashion. but i don't see
>  anyone stepping up to do that right now, nor am i sure it's even
>  realistically achievable with good results ... search systems don't seem
>  to be easily abstractable without rendering them into dumb stores ...

We do have such a lib. Soprano abstracts away several backends already.

The problem is that Nepomuk is the most flexible framework "in the wild" which 
means that the available "native" functionality may be simply inadequate. 

Basically, this is the reason why we had so many issues with soprano backends. 
Even if the backend formally does what we need, it doesn't mean it's useful 
from the practical POV.

In theory, one day someone might write a Spotlight backend for 
Soprano(probably assisted by some other db). In practice, nobody's even 
talking about doing it. So nobody knows when it happens and if it can be made 
at least useful.

> so ensuring nepomuk is available is probably pretty important, imho.
> 
> perhaps outside the KDE Workspace it would be "opt in", in that the user
>  would have to start it up. it could auto-start in the KDE Workspace.
> 
> but it should be available everywhere our apps travel.

This is much easier than trying to integrate with native search.

-- Evgeny