Require Soprano for kdelibs

[Josef Spillner]

Hello Volker,

Am Donnerstag, 6. August 2009 09:03:39 schrieb Volker Krause:
> In general, I think if we want to push the Nepomuk technology and encourage
> applications to use it even for some for their fundamental features, it
> makes sense to ensure that it is available everywhere. After all it's the
> only optional part of kdelibs AFAIK.

this issue is similar to the one we've discussed on IRC the other day. There 
are two stakeholders here: The ones who view it more from the policy side, 
i.e. whether or not we should mandate the use of features, and the ones who 
view it from the dependency or mechanism side, i.e. how modular should KDE 
libraries be.

Let's just assume for a moment that we would like to find a good compromise.

A suitable measure for the discussion would be to have a look at the number of 
entry points to Soprano. Is it most often just called with a single or a few 
lines of code in very few places? In this case, making it optional with easy-
to-use cmake macros would technically be the best choice, and whether or not 
it should be included by default should be solved at another level, not on the 
code level. (I agree that just issuing warnings from CMake doesn't always 
help.) Hiding policy decisions into code is not going to help in the long run.

If there are too many entry points and ways to use the library, then somebody 
should probably rethink its API :)

If on the other hand we do not want a compromise and instead want to provide 
as much bang for the lib as possible, similar to the philosophy of monolithic 
runtime libraries such as Java, this strategy needs to be manifested 
somewhere. The consequence being that it will most likely lead to duplicate 
efforts at one point similar to kdenox/qtextended/JavaME if somebody wants to 
use the libraries for smaller devices, custom appliances etc.

I'm not taking a position here about which way is better, but what kdelibs 
lacks at the moment is a strategy about which way it wants to go, which 
applications we consider KDE applications and which consequences we have to 
expect in return.

Josef