gSoC Implement a better database schema
Thomas Kuther
gimpel at sonnenkinder.org
Thu Mar 26 12:47:27 UTC 2009
On Do, 26.03.09 08:06 Caleb Cushing <xenoterracide at gmail.com> wrote:
> akonadi is meant to be an implementation agnostic data store, is it
> not? I'm not sure how it works (api or anything) but it might we
> worthwhile to migrate to, kinda like amarok 2 migrated to phonon
> instead of doing it's own sound engine management. This would actually
> also solve the fPIC issue because akonadi doesn't do it that way...
> I've also heard there supposed to be a project to support postgres in
> akonadi. perhaps this would be a more worthwhile project.
Thinking one step further, a KDE-whide database abstraction library
would be nice to have. Given you are running a full-blown
semantic-desktop enabled KDE:
* amarok embeds libmysql
* akonadi fires up its own mysqld instance
* nepomuk uses sesame2 as RDF store, and if it will use viruoso in the
furture, that thing fires up a database, application and webserver
if started with a default setup.
* the others I maybe forgot
That's the big database mess. Thank god memory is cheap.
Moving that into a library that everyone can link against and feed it
with a common scheme, and let the user select between 3 major
implementations... that would rock.
I really absolutely prefer postgresql too on my desktop, and would
rather get rid of mysql on the box as I personally never use it
(postgresql ftw), but I can understand the decision made for amarok2.
Just an idea.. not sure how hard it would be and if it's possible at
all to implement that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20090326/7b44c54b/attachment.sig>
More information about the Amarok
mailing list