> 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