This is another post about collection backends in Amarok. The others posts explained the switch to MySQL embedded and tried to address some of the concerns. Jefferai also wrote a few things about Nepomuk in Amarok (and why it will not fully replace the sql based collections) which I want to comment on and add to.
There are user asking: “There is Nepomuk in KDE for storing meta data why the switch to MySQL embedded you could just use Nepomuk and drop sql collection all together.” With reasons like: “Nepomuk can do this and that better and one storage in KDE for everything is best.” They are not complete wrong, there are good reasons to use Nepomuk (data sharing between applications, system wide searching, using strigi(and taglib) for collection scanning at a central place for all applications once, interconnect the data with other data (like let Kmail store where I got that song from), and others)
But Jefferai is right when he says that Nepomuk can not replace the sql collection for everyone and every use case. At least not for the short and longer midterm (;-)).
Why? Not everyone will or could run Nepomuk for different reasons. The most important one: It is a quite complex big software in terms of memory usage (though I think that will improve in time and the amount of available memory in computers is growing fast) and CPU usage. Another issue is: At least in the short and midterm it it will be significant slower than the MySQL based collection. It is not useless slow but well sqlite isn’t useless slow either (faster than Nepomuk atm) and people complained. So: For slower older computers, lightweight media devices, mobile devices, big collections, java “haters” even a perfect done Nepomuk collection with a bug free Nepomuk (we are not there yet…) would be out of question.
I expect some of those issues to improve over time. (I hope we will see a faster C/C++ based storage backend for Nepomuk). But still Nepomuk is a new technology and there is not much experience with it yet amoung users, developers and important here “developing users” (those who create small scripts and apps to work on the sql data from amarok to do different things with that, mostly for their own usage).
Don’t get me wrong: I like Nepomuk and it possibilities for Amarok. It is not useless slow. In fact I am using it as my main collection backend in Amarok for months now. But it is in a similar state as KDE 4 in pre 4.0 days. You could use it but it not feature complete, it is not really stable it has its issues and there will be major changes to some of its parts. Well I hoped to have it (and the related Nepomuk service) in a better shape by now. Sorry for that, my time is very limited at the moment but work has not stopped fully and I am still planing to bring it into a useful shape.
A few words on the Nepomuk service: It will monitor Nepomuk/Strigi for new music and use taglib to read data Strigi can not read (yet?) to fill it. It then creates new music (tracks, artists and so on) resources in the Nepomuk storage. It should also inform interested applications about new music. Overall it aims to have always all music of the user in an easy to access way available for use in media players, music management applications and others.
That should make it easier (and faster!) for Amarok (and others) to use the data.
For example at the moment (ontology not final) to get a QStringList of all artists of the music on the computer in your application is as easy as (when using Strigi, Nepomuk and the unreleased service) :
QStringList artists;
QList<Nepomuk::Resource> artistsResources
= Nepomuk::ResourceManager::allResourcesOfType( "http://purl.org/ontology/mo/MusicArtist" );
foreach( Nepomuk::Resource &artistResource, artistResources)
{
artists << artistResource.label();
}
The flexible Amarok 2 collection framework will allow both (Sql and Nepomuk) collection living together at users choice and maybe in a few years Nepomuk (with faster backend?) could become the default.
)
see you there
