Refactoring done (was: Strigi refactor)

[Jos van den Oever]

2007/3/15, Thomas Zander <zander at kde.org>:
> The problem I have with it is that we see the jstreams namespace seep through
> and the kdebase/graphics/etc code has a mix of both namespaces. Which IMO is
> worse then most solutions you can think of :)
>
> I don't pretend to understand the reasons and problems here, but I thought
> that namespaces were meant to avoid this kind of thing in the first place.
No that's not what namespaces are for. Namespaces are for avoiding
symbol clashes and grouping code.

> Can't we build a layer between the clucene backend and the strigi API to
> isolate anything that happens inside clucene ?
This is what Strigi does, however, in this case clucene actually uses
the same classes with the same names. This is because of a
collaboration between the two projects. Of course we can make an
additional indirection at some additional cost.

> I would find it a bad idea to depend on not one but two external libraries at
> the same time for both binary and source compatibility of our base KDE
> modules.
The classes that are shared between clucene and strigi will remain
compatible. If they are not compatible, we cannot use clucene, but any
other backend or a modified version of clucene.

> I can almost guarantee Murphey will come by somewhere in the approx 5 years
> that I guesstimate the KDE4 framework should stay stable.
We have insurance. There is no way an API change in clucene should
force us into an API change.

There is an easy solution to the problem. The use of pointers and
casting them from one namespace to the other. This should be cheap and
only visible in the cpp files of the cluceneindexer. But it's a bit
ugly and we lose typechecking. I'd prefer a solution where we can
retain that.

Cheers,
Jos