Nepomuk - Changing the Resource class behaviour

[Vishesh Handa]

Hey everyone

( This is a slightly long email )

*History:*

One of the main classes in Nepomuk is called the Resource class. It's
basically just a cache of the resource data (You can imagine it to be a
hash, with properties which contain values - QHash<Property, Value>).

>From the early days, the Resource class has suffered from a problem of
cache invalidation - Another application might change some property of the
resource and the cache wouldn't have been updated. In 4.8 we introduced new
asynchronous APIs. These helped to fix the problem by using a special
ResourceWatcher which worked by subscribing to certain signals over dbus.

With 4.8, each application contains a global static ResourceWatcher who is
responsible to update every Resource's internal cache. ( Slightly
simplified explanation )
*
*
*The Problem:*

Having each Resource class listen for signals over dbus creates a lot of
unnecessary traffic, which slows down certain applications. This is
specially prevalent for resources that are created for very small amounts
of time.

Additionally, applications are not informed that the internal data has
changed. If they wish to be informed, they need to create their own
ResourceWatcher instance, and listen for changes. This is what Dolphin
does. Unfortunately, that also results in another problem - Since the
ResourceWatcher is just listening to dbus signals, we have no way of
knowing which ResourceWatcher's slot will be called first -

1. The Dolphin one
2. Nepomuk Resource update cache one

If (1) happens before (2) and it accesses the cached data, it will result
in it accessing stale information.

Fortunately, Dolphin doesn't suffer from this problem cause it doesn't keep
any Resource objects around. So there is no cache to update.
*
*
*Consequences:*

1. Loads of additional traffic over dbus whenever a Resource is created.
This is done extensively by Dolphin and KMail.

2. Enhanced load of the Nepomuk-Storage to inform all the ResourceWatchers.
This problem is intensified by a Qt bug [1] which resulted in a large
amount of cycles being spent in emitting these signals.

3. Non-documented slightly unpredictable behaviour when using Resources and
ResourceWatchers.

*Possible Solutions:*

1. Add an explicit Resource::setWatchEnabled( bool ) function in the
Resource class which clients can call if they want updates.
*
*
2. Disable this automatic updating all together.
*
*
*When should this be done?

*
I would like to do it in the 4.10 series. Maybe 4.10.1 or 4.10.0? But it
would involve adding a new public function. Otherwise there is always 4.11.
*
*
Currently, no applications depend on this "automatic-updating" behaviour of
the Resource class. Also, this behaviour was never advertised.

Opinions?

[1] https://codereview.qt-project.org/45163

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20130122/0fb68696/attachment.html>