gSoC Implement a better database schema

Colin Guthrie gmane at colin.guthr.ie
Thu Mar 26 22:48:01 UTC 2009


'Twas brillig, and Jeff Mitchell at 26/03/09 19:22 did gyre and gimble:
> Colin Guthrie wrote:
>> 'Twas brillig, and Caleb Cushing at 26/03/09 12:06 did gyre and gimble:
>>> to be honest I think my suggestion is a lost cause, and yet it's
>>> caused me to think of something else I was thinking about.
>>>
>>> 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.
>> Big, big, massive +1 from me!
> 
> Etc., etc., etc.
> 
> Everyone wants this kind of integration, but people need to realize it
> didn't happen before now for legit reasons.  Soprano was slow as #@$%
> and half the distros wouldn't carry the Sesame backend as it was
> distributed in binary form.  Virtuoso is supposed to be faster, but
> we're not sure how fast -- we saw huge performance speedups migrating to
> mysqle from sqlite, and there's not much point in losing them.  Nepomuk
> wasn't started by default on many distros, and using Strigi for scanning
> was a no-go pretty much from the start for many reasons.  Postgres
> sounds nice, except they don't have an embedded library, so people have
> to manually set up their own postgres server.
> 
> Please understand that we are aware of the tech coming along in KDE and
> the changes happening, but just because something sounds nice doesn't
> mean it's usable, or ubiquitous, or stable, or...
> 
> So be patient...we'll move the project to things that make sense when
> they make sense.

Sorry, I didn't mean to sound like I was complaining! I was just trying 
to offer encouragement and support to the student planning to look at 
this with GSoC!

I'm not upset at all about the decisions taken in Amarok 2, and I agree 
with them all! Even looking at the stuff years ago, I knew it was no 
where near mature enough to base things on them back then! But perhaps 
now is the time to help GSoC project participants look into some of the 
possible technologies again?

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]




More information about the Amarok mailing list