--485b390f79fea3dadd04bf125447 Content-Type: text/plain; charset=ISO-8859-1 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 --485b390f79fea3dadd04bf125447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey everyone!

I've been meaning to write this forever, but I'= ;ve gotten sidetracked with real life. Anyway, here it goes -

As som= e of you might know, the Nepomuk source code is distributed over two differ= ent repositories. The client API is in kdelibs, and the rest is in kde-runt= ime.

Developing both of these independently is a little bit of a pain, but w= e (Nepomuk developers) were okay with that. However, ever since Frameworks = 5 was introduced at the Desktop Summit, kdelibs has been frozen. That effec= tively 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 repos= itory - nepomuk-core[1]. This includes all of kde-runtime/nepomuk and the n= on gui parts of kdelibs/nepomuk.

However, maintaining both these rep= ositories has been a major PITA. Cause we need to commit changes twice (som= etimes thrice), once in kde-runtime and the second time in kdelibs/kde-runt= ime. 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 ove= r the course of Dec 2010 - July 2011. And we have switched to these new API= s internally, but the people who use Nepomuk cannot do so, as these new API= s 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 (includ= ing packagers) have complained that kde-runtime should not be a compile tim= e dependency.

So, we need a solution.

The first solution -
* Remove nepomuk= from kdelibs and kde-runtime
* Make nepomuk-core a compile time depende= ncy for kdelibs
* Including the missing gui code into nepomuk-core

The second solution is -
* nepomuk-core installs the headers in nepo= muk2
* 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 Nep= omuk will also need to depend on nepomuk-core. So far the list includes - D= olphin, KDE-pim and Telepathy (kinda)

What do you guys think?

[1] https://projects.kde.o= rg/projects/kde/kdelibs/nepomuk-core
[2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-= management-service/

--
Vishesh Handa
<= br> --485b390f79fea3dadd04bf125447--