Nepomuk in 4.13 and beyond

[Vishesh Handa]

On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote:
> > 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)
> 

There isn't one. Not right now. I'm open to ideas on how to do something like 
if it is required. I'm slightly skeptical if it actually is required.

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

You don't. You just get the identifier and some text. You can do a subsequent 
fetch job to get additional data.

This is however just the generic Query API, if required we can design better 
APIs for something you have in mind. I have some specialized APIs for querying 
PIM data which are more useful in certain cases.

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

Attachments are a strange corner case, in Akonadi, where it isn't really a file 
since it does not have a url, and is not dereference-able. For normal files, 
you currently just get the url.

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

It was designed for Runners, Dolphin, and Email Search. It wasn't designed to 
be a Nepomuk Query API replacement.

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

There is a QueryRunnable class which can be used to run queries in another 
thread. Most backends, do not seem to allow asynchronous queries, so there 
wasn't a way to run queries asynchronously by default.
 
> 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.
> 

I'm open to suggestions on how to implement queries in an async manner.

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

But what if one doesn't use SQL for storing data? IMO Xapian is much better 
suited that sqlite's FTS support (or mysql).
  
I agree with you on the fun query bit, but I'm skeptical if those "fun 
queries" are genuinely required. How about we list down the use cases and then 
see?

When planning Baloo, I've mostly taken a look at PIM, Dolphin, KRunner (and 
Milou), PMC, and KPeople. Perhaps something was missed?

> 
> 
> Cheerio,
> Ivan.

-- 
Vishesh Handa