The Nepomuk Situation

[Sebastian Trüg]

On 05/07/2012 12:09 PM, Vishesh Handa wrote:
> 
> 
> On Mon, May 7, 2012 at 3:12 PM, David Faure <faure at kde.org
> <mailto:faure at kde.org>> wrote:
> 
>     On Monday 07 May 2012 13:06:15 Vishesh Handa wrote:
>     > On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela <nospam at vuorela.dk
>     <mailto:nospam at vuorela.dk>> wrote:
>     > > On 2012-05-07, Vishesh Handa <me at vhanda.in
>     <mailto:me at vhanda.in>> wrote:
>     > > > Right.
>     > > >
>     > > > We could maintain BC and SC by not touching the kdelibs
>     nepomuk, and
>     > > > just
>     > > > making nepomuk-core a dependency of kdelibs. But that would
>     result in
>     > >
>     > > both
>     > >
>     > > > nepomuk-core and kdelibs installing the same headers.
>     > >
>     > > what happens if both libraries are loaded into the same process?
>     >
>     > I'm not sure. I'm assuming that it would result in some sort of linker
>     > errors.
> 
>     Not if libnepomukcore is brought in by the application, and
>     libnepomuk is
>     brought in by a dlopened plugin. In such a case, you get no clear
>     error, you
>     get random crashes.
> 
>     The solution is usually to namespace the symbols (classes, standalone
>     functions etc.) so that they don't conflict.
>     Of course that makes the porting effort a bit higher, but it's the
>     only way to
>     have both things side by side during the transition period.
> 
> 
> Oh.
> 
> So, we're down to 3 options -
> 
> *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched.
> *Problem:* Overlapping headers and possible mysterious crashes if both
> libraries are loaded.
> 
> *2.* nepomuk-core installs headers under nepomuk2. It's released
> independently.
> *Problem:* Mysterious crashes if both libraries are loaded.
> 
> *3.* nepomuk-core installs headers under nepomuk2 and the namespace is
> changed to nepomuk2.
> *Problem:* A lot more work :(

Well, I suppose we could make this work with some sed magic. :P
I would vote for option 3 which could then be reverted (or not) for kde5.

> In all cases, kde-runtime/nepomuk will be removed. Binary and Source
> compatibility are not affected.
>  
> 
> 
>     See knewstuff2 (namespace KNS) vs knewstuff3 (namespace KNS3) for
>     instance ;)
> 
>     --
>     David Faure, faure at kde.org <mailto:faure at kde.org>,
>     http://www.davidfaure.fr
>     Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
> 
> 
> 
> 
> -- 
> Vishesh Handa
>