[PATCH] Making Soprano optional (again) in kdelibs

[Sebastian Kügler]

Hey,

On Tuesday 29 December 2009 19:13:08 Maciej Mrozowski wrote:
>   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*.

I get your point (bloat), but being vague and sarcastic is not the way to go about 
it. The best is to provide numbers to back it up and show the real costs of running 
two databases. I believe they're rather easy to attain, given the right tools, so I 
don't really get why you're coming with a long rant how relational database systems 
bloat KDE (my interpretation), instead of just listing those numbers.

As I said, we also have to look at the costs of maintaining a mandatory dependency 
vs. a soft one (and then runtime dependency against buildtime dependency). And of 
course how this relates to possible target platforms (think mobile / embedded).

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

The initial code for Akonadi was based on sqlite, but due to thread-safety problems, 
a full  MySQL was needed. (I recall talking with Volker about this during Akademy in 
Dublin). The code is not dependant on a specific backend though, and the   sqlite 
backend seems to be coming along now (as is a postgres backend) -- apparently thread-
safety in sqlite has improved to a point where it becomes viable again.

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

In the light of what I write above, this sounds rather uninformed to me.

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

Can we drop this kind of silliness?

Semi-related: There's an effort going on putting bookmarks into Akonadi, not sure 
about history, though.

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

Thread-safety is about async access for multiple clients, not the server (there is 
none in the case of sqlite to my knowledge).

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

Not really, numbers would.

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

The real issue hasn't been fixed. That's what Allen's email is about. What I wanted 
to know about is a *specific* problem (i.e. "this won't work because ..."). Your 
email is rather hand-wavy. 

Note that I, too, would like to keep KDE's footprint small, but going "OMG two 
databases!!!!!!!!111111" shortly before RC1 is unproductive.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9