ksycoca and kbuildsycoca, the next step

[David Faure]

On Sunday 06 September 2015 17:59:13 Matthew Dawson wrote:
> On September 6, 2015 01:52:37 PM David Faure wrote:
> > 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:
> Everything looks good from me, just one comment:
> 
> > 
> > 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)...
>
> Instead of killing the kded component completely, could we instead make it 
> optional?  That way in a full KDE session, we monitor the directories as 
> needed so we don't loose the file watching.  Then if an application using 
> KService is launched outside the session, it falls back to this behaviour.
> 
> Though the problem from point 4 still exists.  Maybe make the signal be 
> specific to the cache?  Since that would be more work then just a straight 
> port that no one has time to write, I wouldn't care if the kded component is 
> killed off currently, as long as it isn't a problem to bring back in a future 
> version where it would be useful.

I'm missing one point in your reasoning: what would we gain from keeping
the kded code that watches desktop files and runs kbuildsycoca,
if the apps do the same anyway, any time they need the sycoca contents? 

I guess this is an answer to my thoughts about the possible issue with nobody
noticing a change for a long time, but I'm not sure the problem really exists.

Hmm. Best way to find out is to look at all users of the databaseChanged signal,
I guess. I'll do that then.

I'd like to avoid solutions with "options" because it's more maintainance and
more chances that the non-full-desktop case breaks (due to being less
tested by most of us).

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