Nepomuk as hard dependency in future?

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

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

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.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091019/c0018b02/attachment.sig>