[PATCH] Making Soprano optional (again) in kdelibs

[Maciej Mrozowski]

On Tuesday 29 of December 2009 13:50:12 Sebastian Kügler wrote:
> On Sunday 27 December 2009 14:34:23 Maciej Mrozowski wrote:
> > While keeping if (NEPOMUK_FOUND) and alike CMake code is considerable
> > maintenance cost - this cost has already been born so there's nothing
> > else
> > 
> >  to  do for 4.4 (and dropping this code to simplify CMake files relying
> >  on the fact that Nepomuk libs being mandatory would cause another
> >  maintenance cost).
> 
> Wrong, keeping ifdef's brings long-term testing and maintainance costs, as
> you basically get two branches in one code base, which means that testing
> for each of those branches is cut down, and some new code has to be
> written for two scenarios. That's why we try to reduce these cases to an
> absolute minimum.

That's of course true and I agree (still making such change for 4.4 is risky 
as it's easy to break something in the process and time is running out).

One little problem remains - in case no one noticed - *KDE* *SC* is now (as of 
4.4) *officially* *the* *first* *Desktop* *Environment* *in* *the* *history* 
*that* *requires* *two* *full*-*blown* *relational* *database* *servers* 
*running*.

While Nepomuk has been made to need SPARQL-aware storage and it actually 
stores real *data*, choosing relational database server (OpenLink Virtuoso in 
this case) is somewhat justified.

Now *funny* part - Akonadi.
The *idea* is *great* - PIM resource access abstraction layer.

Let's try to justify the use of relational database server.
Applications' configuration used to be stored in KConfig and indeed there are 
some akonadi_ xxx_resource_xxx* files in ~/.kde/share/config
Akonadi server is pure Qt4 application so can't use KConfig probably, but in 
${XDG_CONFIG_HOME}/akonadi there are "ini" files so it is possible not to use 
database to store configuration application, apparently..

Akonadi developers think otherwise as nearly all tables in akonadi database 
are used to store... *configuration* like resource mappings, mimetypes, flags, 
various properties, achieving impressive number of 11 1NF compliant (a few 
exceptions) relations with just one (parttable) storing anything *relevant* - 
actual data.
Sort of - as it's cache actually as data persistency is elsewhere.
Cache = temporary, *volatile* data, implemented by some proxy layer - 
introduced only to gain performance, let me remind.

So... considering there are so many disk database systems (like berkdb, gdbm) 
I can't find any justification for adding complexity by relying on full-blown 
SQL database for storing configuration (11 tables is not 70, still it's 
shooting a fly with cannon).
Also having larger relation count and in-database data integrity via foreign 
keys is of course great excuse to dump SQLite and libmysqld (MyISAM) which is 
otherwise ideal solution as it's embedded database (a'ka "I don't need to care 
about setting it up nor it drains significant amount of system resources").

Akonadi was probably initially meant to provide real storage and persistency 
layer for PIM resources, code was written, and when it appeared it's not the 
way to go, it was too late to get back. I would understand that (but only 
that).

Also I think it's just a matter of time when someone finds konqueror browsing 
history too slow with big history (that's actually fact - list seems to be 
searched linearly - bug 206900) and decides to write relational database 
backend for it (which is actually good idea provided small & fast embedded 
database is used) and then *totally* "screws" the design by overengineering it 
by creating multiple relations with academic 3NF (or better) approach.
Then as a consequence thinking that SQLite is too "silly" for that purpose and 
for instance preferring PostgreSQL with argumentation along the lines "why 
not, it's serious database server after all and I use it™".
Isn't it what Akonadi techbase indirectly says about MySQL (InnoDB)? Also 
promptly noting lack of thread safely in SQLite despite the fact there's just 
one akonadi server instance supposed to be run and the one is not supposed to 
be shared among users as it's not groupware server.

I guess I'll start writing konqueror history backend using PostgreSQL 
exclusively (dfaure won't let me .... <sad panda/>....fortunately),
Klipper probably needs some good backend too - SQL is trendy nowadays and I 
heard IBM Db2 is good. Screw common sense - *who* *does* *the* *job* - 
*decides*, it's never too many database servers running in user's desktop 
environment.

I think all above justifies my actions towards making Nepomuk (and thus 
virtuoso) not mandatory wherever possible.

> What are your *specific* problems with the soprano dependency?

This has been fixed by making Soprano check non-fatal.
It's been laid out in initial email to kde-buildsystem:

<quote>
Now, in kdelibs there's a little inconsistency with Nepomuk related CMake 
options logic:
- Soprano is always required (unnecessarily)
- SDO is optional
- Nepomuk libs are built when both Soprano (with all needed backends and 
parsers) and SDO are found

If SDO is optional then there's no need to force to Soprano required,
and if Soprano is required then there's no need to guard
add_directory(nepomuk) with Soprano_FOUND and thus whether to build
Nepomuk libs only depends on SDO presence,....but only when Soprano is
found...
</quote>

-- 
regards
MM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20091229/645a5329/attachment.sig