Projects/Nepomuk/Irc meeting nepomuk frameworks: Difference between revisions
m moved Irc meeting nepomuk frameworks to Projects/Nepomuk/Irc meeting nepomuk frameworks: this page is part of Nepomuk, it should be in that tree |
|||
| Line 13: | Line 13: | ||
* Which parts do we drop (besides the already deprecated API) | * 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) | * 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? | * What do we do with [http://api.kde.org/4.x-api/kdelibs-apidocs/nepomuk/html/classNepomuk_1_1ResourceManager.html#ad6316112419b8b0d089358e598804673 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 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 [http://quickgit.kde.org/?p=kdelibs.git&a=blob&f=kio/kio/kdirnotify.h KDirNotify] signals. | * 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 [http://quickgit.kde.org/?p=kdelibs.git&a=blob&f=kio/kio/kdirnotify.h KDirNotify] signals. | ||
Revision as of 12:03, 29 August 2011
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:
- Tier 1: components which only depend on Qt and no other lib/component from KDE
- Tier 2: components which depend on Qt and other libraries from Tier 1.
- Tier 3: components which depend on anything
Due to our central runtime parts basically all our components are in Tier 3. The only exception is Soprano which is in Tier 1.
The goal of this meeting is to determine what to do with Nepomuk in KDE 5.
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.