Re: Common music database?

Just btw, in case this point isn't made strong enough: Our relation type library is a _replacement_ for any kind of SQL based systems. You simply deal with relations ( as data types instead of manipulating them trough SQL. It features referential integrity and has all basic operations that are at least needed for something like metadata storage for a media player. It's not Oracle, and it's not Postgres, but it can replace sqlite3 anytime, and it sure can take on MySQL if you don't excess (it's also extensible btw the same way GTK+ is extensible as it's based on the Glib GObjet system).

This means, we have an entirely different way of dealing with relations ("tables") and tuples ("rows") that contain metadata for a file. And yes, we can perform queries just like you would with SQL, just that we don't use SQL. And yes, we can do JOINs and PROJECTs and INTERSECTs and whatever else.

Moving to tracker would basically mean for us to throw this away which is not an option at all, and i'm sure that we aren't the only player around that uses an own system to store it's metadata (our system has vasts benefits over embedding or accessing SQL btw, which i am readily willing to discuss or explain on request). The other option would be an libhrel <--> Tracker connector (i've written one that uses sqlite3, but only as the raw storage, we don't perform SQL operations within it, but use it only to store the metadata between sessions; normally our app uses R/T FS (Relation/Tuple Filesystem), a filesystem-like thing i've written to store the raw data off-session).

Just to point that we're really serious with this and libhrel is not some toy library and that we have serious reasons why we're using it, and why we *developed it ourselves* as well just for the purpose of BMP experimental; it's grown beyond itself now as a lot of projects do, but it was originall written for BMP.

On 3/31/06, Milosz Derezynski <internalerror gmail com> wrote:
Well Tracker looks certainly very cool (really), but this brings up the problem again that each player has it's own way of dealing with metadata internally, and the question is how much do we want to spec here?

For example in BMP experimental (the `bmpx' repository in our SVN), we use, as i've already said, a relation type library and hence there's no much use for us for an SQL or SQL based, or otherwise query based external system apart from the _raw storage_.

Tracker again isn't just raw storage, it's somewhat more, and i dare to say that any player that would want to make full use of Tracker as the (shared) metadata/database backend would have to either sacrifice a lot of own features it supports, or have really a lot of very whacked and very weird code (as bindings always tend to have a lot of blood and bonesplitter in them).

So to put the point: _How much_ do we want to spec here? And Sriram, since you hinted us towards Tracker, what was your intent or what do you think on this issue?

(Just for the sake: In our case it would basically mean throwing away our entirel relation type library, or writing some kind of connector between that and Tracker, which runs down to exactly the 2 options i've mentioned above, and of which none sounds very pleasing to me.)


On 3/30/06, Sriram Ramkrishna <sri aracnet com > wrote:
So I'm trying to restart this thread again.  I was talking to Jamie
McCracken about Tracker, his replacement for medusa.  He has some
interesting ideas about using it as a music backend.  Tracker is
an extensible metadata daemon, as well as an indexer.

So the nice win we could get is that we would no longer need to
import music into the player but they would automatically show up.  Plus it has support for tags and various other goodies.

More information here:

You can get it from GNOME CVS apparently, and uses an embedded
mysql database.

The one main advantage I see is that it already has a full DBus API.

Hopefully, Jamie has subscribed and he can talk more about it.


gnome-multimedia mailing list
gnome-multimedia gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]