Nepomuk in 4.13 and beyond
Ivan Čukić
ivan.cukic at kde.org
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.
Cheerio,
Ivan.
--
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