[PATCH] Making Soprano optional (again) in kdelibs
Maciej Mrozowski
reavertm at gmail.com
Tue Dec 29 19:13:08 CET 2009
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/release-team/attachments/20091229/645a5329/attachment.sig
More information about the release-team
mailing list