Nepomuk as hard dependency in future?

[Volker Krause]

On Tuesday 20 October 2009 03:50:42 Evgeny Egorochkin wrote:
> В сообщении от Вторник 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, there is libQtTracker, which is based on a Soprano fork and has a Tracker 
backend for that. AFAIU it is incompatible with our Soprano, it might allow a 
Soprano Tracker backend in the future though.

> > (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.

I fully agree.

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

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.

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/6d87d878/attachment.sig>