Require Soprano for kdelibs

[Volker Krause]

On Thursday 06 August 2009 09:29:59 Josef Spillner wrote:
> 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.

From a purely technical point of view I'm all for making things 
optional/modular.

However, experience with that in KDE PIM (eg. cyrus-sasl for various mail 
server authentication methods, to name just one example) shows that this can 
cause considerable support load since not everyone pays attention to the 
CMake output regarding the effects of missing dependencies. If I can't even 
rely on distros doing that correctly (most of them do fortunately), my only 
option to ensure that the majority of our users get a fully working 
application is to enforce the dependencies unfortunately :-/

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090806/b7fac1c5/attachment.sig>