Shared data in KnewStuff3 ideas

[Ingo Klöcker]

On Saturday 23 October 2010, Matthias Fuchs wrote:
> 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.
> 
[snip]
> 
> ====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.
> 
[snip]
> 
> ====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?

This does indeed sound similar to what Akonadi does, but Akonadi is not 
the solution. Akonadi's problem-space is well defined: centralized 
access to PIM data. Akonadi was not designed to provide access to any 
kind of data.

Having said this, it surely cannot hurt to have a look at the design of 
Akonadi and build something similar (but much simpler) for KNewStuff*.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101023/9ee90092/attachment.sig>