Shared data in KnewStuff3 ideas

[Matthias Fuchs]

Hi,

====Problem description====
Currently there is a major flaw in KNewStuff3. All the caches are not shared, 
not in the same process and not over processes.

This way it can happen, that e.g. KNS3::DownloadManager updates some 
KNS3::Entries and a call to KNS3::DownloadWidget later on would overwrite the 
updated ones as updateable.
Also having two instances of kpat, installing a theme in one, closing it and 
later closing the other instance -- which just displayed a 
KNS3::DownloadWidget -- of kpat would result in the theme marked as not 
installed in the KNS3::DownloadWidget.

Especially the first issue is a quite serious one, since it essentially  makes 
it hard to impossible to automatically update something. Why you may ask?
The Cache is only written to the hd once the Engine that has it as member is 
destroyed. Thus the only way for the KNS3::DownloadManager  to work if the 
user plans to open KNS3::DownloadWidget later on would mean that users have to 
quit the program -- e.g. plasma-desktop in the comic case -- that did an 
update. Kinda defies the sense of an auto-update.

====Proposal====
Here "local" means the process that wants to use KNewStuff.

What I propose now is a two step solution. First of all sharing the Cache 
(interal cache = ic) in the same process, I have created a patch for that 
already see [1]. This fixes the issues with comics outlined above.

And the second is to share the interal entry data in an own process and 
retrieving/setting it via DBus. The way I think of it -- not implemented yet 
-- is that an own application knewstuff3cache  (kc) will handle all the 
retrieving and storeing of the entry data.

It would work the following:
1. When ic is created for an app -- e.g. comic --  it creates an adaptor to 
talk to kc, that adaptor itself starts kc if it was not running yet, kc will 
then load the kns-registry files and convert old kns2 files if needed, all the 
data is then stored in EntryData classes.
2. When ic is being asked to return a list of EntryInteral for a certain 
provider the adaptor will send that request to kc which in turn sends all the 
EntryData over DBus, now a list of EntryInternal is created with an EntryData 
as member each, thus the EntryData is locally cached
3. Whenever something requests data from EntryInternal the data will be gotten 
from EntryData
4. Now if something sets new data via EntryInternal the data won't be set in 
the EntryData of EntryInternal directly, instead the change is send over DBus 
to kc, which changes its instance of EntryData and emits an entryChanged(int 
typeOfChange) signal
5. EntryInternal is connected to that signal and updates the changed data, it 
could emit a signal itself to update any uis displaying its data

As all the touched classes are internal I think this would not be an ABI 
problem.

====Discussion====
What do you think of that idea? Are there better -- and especially -- easier 
ways to do what I want?
Should this rather be part of a KNewStuff4 that moves all the KNS-handling to 
an own process and offers access-methods via DBus, though one problem would be 
how to handle the DownloadWidget then.
Or maybe should Akonadi be used for all that? But if it should be used, could 
it be added as dependency to knewstuff -- which is in kdelibs?

Etc.

So please go ahead and comment. :)


[1] http://reviewboard.kde.org/r/5528/