[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: The Nepomuk Situation
From: Vishesh Handa <me () vhanda ! in>
Date: 2012-05-02 19:14:37
Message-ID: CAOPTMKDb7kKYyrS+ng-Bn_sCpdX4JK7wAkYurTYKQncifyp0Jw () mail ! gmail ! com
[Download RAW message or body]
Hey everyone!
I've been meaning to write this forever, but I've gotten sidetracked with
real life. Anyway, here it goes -
As some of you might know, the Nepomuk source code is distributed over two
different repositories. The client API is in kdelibs, and the rest is in
kde-runtime.
Developing both of these independently is a little bit of a pain, but we
(Nepomuk developers) were okay with that. However, ever since Frameworks 5
was introduced at the Desktop Summit, kdelibs has been frozen. That
effectively means that we cannot develop the client side libraries. At
least no radical changes.
Meanwhile with the frameworks effort going on, we created our own
repository - nepomuk-core[1]. This includes all of kde-runtime/nepomuk and
the non gui parts of kdelibs/nepomuk.
However, maintaining both these repositories has been a major PITA. Cause
we need to commit changes twice (sometimes thrice), once in kde-runtime and
the second time in kdelibs/kde-runtime. This is often quite hard cause
nepomuk-core's directory structure is quite different from kde-runtime +
kdelibs.
The second problem is the introduction of new Nepomuk APIs, also called the
Datamanagement APIs [2]. We implemented this whole set of new APIs over the
course of Dec 2010 - July 2011. And we have switched to these new APIs
internally, but the people who use Nepomuk cannot do so, as these new APIs
cannot be shipped. Mainly cause kdelibs is frozen. We have partly solved
this by distributing the headers in kde-runtime and by some people making a
copy of the library (Dolphin and KDEPIM). However, a lot of people
(including packagers) have complained that kde-runtime should not be a
compile time dependency.
So, we need a solution.
The first solution -
* Remove nepomuk from kdelibs and kde-runtime
* Make nepomuk-core a compile time dependency for kdelibs
* Including the missing gui code into nepomuk-core
The second solution is -
* nepomuk-core installs the headers in nepomuk2
* the library already has a different name, so there are no clashes over
there
* kde-runtime/nepomuk is removed
* nepomuk-core is added as a dependency of kde-runtime
The problem with the second solution is that all applications using Nepomuk
will also need to depend on nepomuk-core. So far the list includes -
Dolphin, KDE-pim and Telepathy (kinda)
What do you guys think?
[1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core
[2]
http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management-service/
--
Vishesh Handa
[Attachment #3 (text/html)]
Hey everyone!<br><br>I've been meaning to write this forever, but I've gotten \
sidetracked with real life. Anyway, here it goes -<br><br>As some of you might know, \
the Nepomuk source code is distributed over two different repositories. The client \
API is in kdelibs, and the rest is in kde-runtime.<br>
<br>Developing both of these independently is a little bit of a pain, but we (Nepomuk \
developers) were okay with that. However, ever since Frameworks 5 was introduced at \
the Desktop Summit, kdelibs has been frozen. That effectively means that we cannot \
develop the client side libraries. At least no radical changes.<br>
<br>Meanwhile with the frameworks effort going on, we created our own repository - \
nepomuk-core[1]. This includes all of kde-runtime/nepomuk and the non gui parts of \
kdelibs/nepomuk.<br><br>However, maintaining both these repositories has been a major \
PITA. Cause we need to commit changes twice (sometimes thrice), once in kde-runtime \
and the second time in kdelibs/kde-runtime. This is often quite hard cause \
nepomuk-core's directory structure is quite different from kde-runtime + \
kdelibs.<br>
<br>The second problem is the introduction of new Nepomuk APIs, also called the \
Datamanagement APIs [2]. We implemented this whole set of new APIs over the course of \
Dec 2010 - July 2011. And we have switched to these new APIs internally, but the \
people who use Nepomuk cannot do so, as these new APIs cannot be shipped. Mainly \
cause kdelibs is frozen. We have partly solved this by distributing the headers in \
kde-runtime and by some people making a copy of the library (Dolphin and KDEPIM). \
However, a lot of people (including packagers) have complained that kde-runtime \
should not be a compile time dependency.<br>
<br>So, we need a solution.<br><br>The first solution -<br>* Remove nepomuk from \
kdelibs and kde-runtime<br>* Make nepomuk-core a compile time dependency for \
kdelibs<br>* Including the missing gui code into nepomuk-core<br>
<br>The second solution is -<br>* nepomuk-core installs the headers in nepomuk2<br>* \
the library already has a different name, so there are no clashes over there<br>* \
kde-runtime/nepomuk is removed<br>* nepomuk-core is added as a dependency of \
kde-runtime<br>
<br>The problem with the second solution is that all applications using Nepomuk will \
also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and \
Telepathy (kinda)<br clear="all">
<br>What do you guys think?<br><br>[1] <a \
href="https://projects.kde.org/projects/kde/kdelibs/nepomuk-core" \
target="_blank">https://projects.kde.org/projects/kde/kdelibs/nepomuk-core</a><br>[2] \
<a href="http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management-service/" \
target="_blank">http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management-service/</a><br>
<br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic