Nepomuk in 4.13 and beyond

Ivan Čukić ivan.cukic at
Thu Dec 12 18:40:11 GMT 2013

> If we all decide to store stuff in sqlite, then it doesn't matter if they
> are separate database files or the same one.

I might be missing a few things here, but asking questions is the road to 
enlightenment :)

- There is no way to query across different stores, which was the main appeal 
of nepomuk? (I concluded this from the last mail)

- When querying, how do I get the properties of the results?

When asking for the attachments sent by Alice, I don't care only about the id, 
title and the icon of the result. I'd like to get the mimetype, size etc. (for 
example, to group the results), or for further processing if I have no desire 
to show the results directly to the user. Can I retrieve those with baloo api? 
Do I need to make separate queries for those?

The Result class looks like it was tailored only for displaying the results to 
the user - KRunner style (design of it all looks quite similar to KRunner to 
be honest).

- We talked about asynchronous querying. Is it going to happen? 

I see a lot of KJobs for altering stuff, but Query and ResultIterator do not 
look async.

Just imagine a store that wants to query currently open windows (via dbus 
connection to kwin), or currently open documents for an activity (requires 
connection to both kamd and kwin). It can not be done sanely in a synchronous 
way. One of the main things in libkactivities was to make everything be 
totally async.

- Database integration

When we talked about the nepomuk successor at Akademy, one of the main 
benefits I saw at the time was the possibility to integrate all dbs into one 
(and shut up all the people who complain we like dbs too much :) ). Baloo 
seems to go out of its way to accommodate the fact that everybody is using 
different things (be it mysql, embedded mysql, sqlite, plain text etc.).

>From my POV, it would be much nicer if you forced a single db (as an actual 
store, not as a cache like nepomuk is for akonadi) on the people, with the 
option to have a few things runtime defined. It would ease the development and 
would allow more fun queries which would be optimized unlike the manual 
client-side joining of different query results.


Progress isn't made by early risers. It's made by lazy men trying to find
easier ways to do something.
  -- Robert Heinlein

More information about the kde-core-devel mailing list