ksycoca and kbuildsycoca, the next step

[David Faure]

As a followup to recent discussions, I'm now looking into moving the recreating
kbuildsycoca directly into the kservice library.

The rebuild now happens on demand when using any KService API and one the
dirs with desktop files is more recent than the sycoca cache (that part is
already in), so the next steps are:

1) kded no longer needs to watch the dirs with desktop files.
I assume even the K menu doesn't just keep a cache of everything in memory, and use
the KService/KServiceGroup API every time it's opened, so it should get the new stuff.
However on demand means the old DBus signal databaseChanged() is either killed
or at rebuild time by the app doing the rebuild (which could be later than when using
file watching; possibly a very long time if no app calls into KService for a long time)...

2) kbuildsycoca5 will be kept as a way to force it to happen, but in theory it will be
only needed when someone edits a .desktop file by hand (I checked, and "make install"
touches the mtime even if an older version of the .desktop file was there, so that's fine).

3) Killing the mostly unused --checkstamps and --checkfiles options for kbuildsycoca.
Its job of the app to trigger a rebuild, no point in having options for "no rebuild needed after all"
in kbuildsycoca. I don't think anyone used these anyway.

4) I have one problem though. There is the case where the existing sycoca file, which was built for
a given language, and a given set of XDG_DATA_DIRS, doesn't match the language and dataDirs of
the running application. kbuildsycoca had code to detect that and discard the existing sycoca in
that case (basically assuming --noincremental then).
But if this logic moves to the apps (which would solve the long-standing issue of "kded is watching
different dirs than what I set in my shell so the sycoca doesn't have what I need"), we have a possible
bad scenario where two apps are running with a different language or dataDirs, then every time they look at
sycoca they will think "there is a mismatch, I need to rebuild it". And every 5 seconds these two apps
would rebuild sycoca to their liking, playing ping pong with it.

In the freedesktop discussions around caches (shared-mime-info and the still-vapourware desktop file index)
the idea was to have one cache per directory rather than one local cache which merges everything,
which gets rid of the "different dataDirs" issue, and to have all languages in the cache, so no need to
rebuild when changing language. But that's a much bigger redesign step for ksycoca which I'd like
to avoid (one step at a time...).

Any idea on how to avoid cache-rebuild ping pong?

I can only think of one cache per (lang, dirs) combination somehow, but that seems tricky
(a config file to point to some randomly generated filename for each combination?).
That's quite some code for a case that rarely happens (but well, not handling this case
was exactly the reason for the 15-years-old issue of "I export KDEDIRS from a konsole
to add the install prefix of one app with plugins, and the app doesn't find its plugins because
the session-started kded (which runs kbuildsycoca) doesn't know about that dir".

Any feedback on the rest of the plans concerning ksycoca?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5