[PATCH] Making Soprano optional (again) in kdelibs

[Mike Arthur]

On 29 Dec 2009, at 18:13, Maciej Mrozowski wrote:

> 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*.

Writing like this doesn't make your point any better, it just makes it harder to read.

> 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.

If you are going to troll the KDEPIM developers then you might consider actually CCing them in so they can defend themselves.

http://techbase.kde.org/Projects/PIM/Akonadi#Why_not_use_sqlite.3F

You've clearly not looked very hard to try and find the reasoning for this. Talk to the Akonadi developers and they will elaborate further. I'm lucky enough to have worked with some of them for fun, some of them for work and met a fair few of them. They are smart guys and if they decided the MySQL dependency was really necessary then I trust them on that. If you think that SQLite can be easily used instead then write a patch and make it an option and I'm sure, like the PostgreSQL one, it will be included as an option.

Writing code is a productive way of solving these disputes rather than criticising other people's code.

> 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.

Then what was the need for the rant?

--
Cheers,
Mike Arthur
http://mikearthur.co.uk