Projects/Nepomuk/Irc meeting nepomuk frameworks

Topic

For KDE 5.0 kdelibs and kde-runtime will be split into several parts/components/repositories in order to be more modular and reach a larger audience. This development is at the moment going on in the frameworks branch of kdelibs. There is basically three groups of repositories:

1. Tier 1: components which only depend on Qt and no other lib/component from KDE
2. Tier 2: components which depend on Qt and other libraries from Tier 1.
3. Tier 3: components which depend on anything

These three groups are categorized into Solutions, Qt Addons (OS Integration), and Qt Addons (Functional).

Items of Discussion

• How do we split libnepomuk for kdelibs 5.0
• Which parts do we drop (besides the already deprecated API)
• Which new parts do we introduce (candidate: nepomukdatamanagement) and how do we combine them with existing libs (maybe merge)
• What do we do with ResourceManager::mainModel()? Do we drop it altogether? Do we introduce an alternative which is purely DBus based? Do we extend the QueryServiceClient to provide better SPARQL result support?
• We need to move nepomuk-dependent code from KIO to our libs
• We need to make the rest of KIO independent of Nepomuk. This is mainly the download tracking. David Faure suggested to introduce a DBus signal which one of our services can connect to. Maybe similar to the KDirNotify signals.

Participants in IRC meeting 29.08.2011 and 30.08.2011

• Vishesh Handa
• Artem Serebinsky
• Sebastian Trueg

Decisions

Git Repositories

Which repositories will we use and which components will they contain. The decision was based on the question of which parts of Nepomuk we want always to be available and which are optional.

1. nepomuk-core - The main Nepomuk repository which is required in any case and provides the basic Nepomuk functionality including storage, query, and the like. Draft repository can be found in trueg's nepomuk-core scratch repo.
   • Nepomukserver
   • nepomukservicestub
   • Extension ontologies
   • Core services: Storage/DMS, Query service, Filewatch service, File indexer
   • Core libraries: see below.
2. nepomuk-ui
   • UI libraries: see below
3. nepomuk-kde-kio
   • KIO slaves: nepomuksearch, timeline, nepomuk
4. nepomuk-kde-config-ui
   • nepomukcontroller
   • Nepomuk KCM

Libraries

New Libraries

Which libraries do we want to have in the end?

1. nepomukcore - The core libraries which are always installed and everything else depends on
   • libnepomukdatamanagement
   • The current kdelibs/nepomuk/core
   • The current libnepomukquery
   • The current kdelibs/nepomuk/types
   • Nepomuk::formatPropertyValue - maybe rename to propertyToString to indicate that it is the basic formatting method
2. nepomukui - UI elements build upon nepomukcore
   • The current kdelibs/nepomuk/utils/searchlineedit.h/.cpp, searchwidget.h/.cpp
   • KFileMetaDataWidget - with a new name and in Nepomuk namespace (is in dire need of a rewrite)

API to drop

• For now we drop the facet API and move it to playground since it was forced and is weird
• We drop all in kdelibs/nepomuk/ui from public API and only copy what we need for the metadatawidget
• We will drop ResourceManager as a public class.
• We will drop QueryServiceClient and replace it with methods in the Nepomuk namespace that return job instances which will then signal the results.

Queries

We currently have the async QueryServiceClient API and the sync Soprano APi provided through ResourceManager::mainModel. The goal is to have one way to query Nepomuk in order not to confuse developers. This one way should allow for use of Nepomuk::Query::Query or a SPARQL string. The result type would depend on the query method used - for SPARQL strings it should return bingings, for Query instances it should return something simpler like Nepomuk::Query::Result.

The road to take is this:

• Drop the mainModel method together with the whole of ResourceManager.
• Drop QueryServiceClient and instead add query methods into the Nepomuk namespace which return jobs or query instances that provide result signals and can be synchronously iterated with a method like waitForNext. This method would ideally not use a local event loop but wait for the socket to give more information.
• Merge Query service into storage service for faster queries
• Unless kernel DBus is finished quickly we should keep the socket communication for queries. Otherwise the DBus daemon goes crazy.

The quickest way to achieve the above would be to introduce two query methods:

1. An asynchronous query method which takes a Nepomuk::Query::Query as parameter and internally runs through the query service.
2. An executeQuery method which takes a SPARQL string as input and internally uses the Soprano::Client::LocalSocketClient to connect to the storage service. This method would return a Nepomuk::Query::ResultIterator which would essentially be a wrapper around Soprano::QueryResultIterator but would hide the Soprano API entirely from the public Nepomuk API (important to allow binary changes in Soprano even between Nepomuk releases).

The advantage of this approach is that it can be realized without much changes in the backend. This means less work and a quicker solution. The disadvantage is that there is no real asynchronous way to execute SPARQL queries. However, seeing that plain SPARQL queries are more intended for internal queries rather than for anything shown to the user this might be not such a big problem.

Embedding the LockSocketClient into the ResultIterator also solves our nasty de-connection problems since with every query a new connection to the storage service is created.

Dependancies on Nepomuk in kdelibs

We were asked to get rid of hard Nepomuk dependancies in kdelibs if possible. It actually is quite possible and this is how we will do it.

KIO

Currently KIO contains classes that depend on Nepomuk. We will move those into nepomuk-ui. Basically it is only the KFileMetaDataWidget.

KParts

browserrun_p.h contains a class to Nepomuk::Utils. This will be replaced by a DBus signal as follows:

void emitFileDownloaded(const QString& srcUrl, const QString& destUrl, const QString& referrer, int startTime, int endTime);

Which is in sync with the design of KDirNotify. One might even think about making this a desktop standard.

Nepomuk::Resource

The code and API of Nepomuk::Resource is one of the oldest part of Nepomuk. Its API will be cleaned up considerably. Besides the already mentioned removal of ResourceManager we will make use of QObject. "Make use" here means that conceptually Nepomuk::Resource will be derived from QObject to provide change signals. Effectively, however, it will not be derived from QObject since that would prevent fancy multi-inheritance in generated sub-classes. Instead we will provide a watcher method which returns a QObject derived class. This class provides the required signals instead.

namespace Nepomuk {
class Resource {
    [...]

    ResourceWatcher* watcher();

    [...]
};
}

Here "ResourceWatcher" is not the same as the existing ResourceWatcher class which allows watching arbitrary resources. (The naming clash has still to be resolved.) Instead it has signals which only relate to the resource in question:

namespace Nepomuk {
class ResourceWatcher : public QObject {
    Q_OBJECT

Q_SIGNALS:
    void resourceChanged();
    void resourceRemoved();
    void propertyAdded(const Nepomuk::Types::Property& prop, const QVariant& value);
    [...]
};
}

(The type of the parameters is yet to be decided - it is not clear if we will keep Nepomuk::Variant or not.)

Resource Generator (rcgen)

Currently we have two rcgen implementations:

1. The (old) rcgen which creates sub-classes of Nepomuk::Resource and is implemented in C++. This one is hard to maintain and full of hacks.
2. The (new) rcgen which creates sub-classes of Nepomuk::SimpleResource and is implemented in Python.

The goal is to make the new rcgen written in Python support creating sub-classes of Nepomuk::Resource. This should be fairly easy as most of the code is the same.