Re: Common music database?

["Milosz Derezynski" <internalerror gmail com>]

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
(http://en.wikipedia.org/wiki/Relational_model) 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.)

--Milosz

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:

http://freedesktop.org/wiki/Software/Tracker

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.

sri

_______________________________________________
gnome-multimedia mailing list
gnome-multimedia gnome org
http://mail.gnome.org/mailman/listinfo/gnome-multimedia