The Nepomuk Situation

[Vishesh Handa]

On Mon, May 7, 2012 at 3:12 PM, David Faure <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> wrote:
> > > On 2012-05-07, Vishesh Handa <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 :(

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, http://www.davidfaure.fr
> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
>
>


-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120507/8c4d52ab/attachment.htm>