Shared data in KnewStuff3 ideas
mat69 at gmx.net
Sat Oct 23 18:13:39 BST 2010
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.
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 . 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
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
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
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?
So please go ahead and comment. :)
More information about the kde-core-devel