Re: Common music database?

On Mon, 2006-03-13 at 16:05 -0500, Aaron Bockover wrote:
> I would absolutely vote for a sqlite3-based database. The speed and
> stability is unparalleled. The ability to support transactions is also a
> major bonus, not to mention there's no need for inventing some arbitrary
> query language, so features like smart playlists and advanced searching
> can more or less fall into place with fair ease.
> d) On second thought, it would be nice to have maybe <buzz>pluggable
> backends</buzz>: an "I'll always be there" sqlite3 backend, but I am
> exploring using just Beagle as a library backend for Banshee, and that
> would be really cool: Beagle manages the index, querying, tagging,
> metadata, etc.

We definitely need to decide whether we want shared database
storage/query (e.g. a sqlite database we all agree to use) or a shared
full database layer.

While shared-storage would be easier (as app authors wouldn't need to
change their existing db layer), a shared database layer would probably
be better, as it would help stop a lot of code duplication.

Milosz mentioned the "arbitrary query language"/db layer that BMPx has;
here is a quick overview of Rhythmdb (Rhythmbox's db layer).

There are three main parts: the low-level backend abstraction, the
high-level database services and some utility stuff (which is somewhat
Rhythmbox specific).

The low-level bit is just a backend abstraction; currently we only have
the "Tree" backend (which stores the db as a object-based heirarchy in
memory, and xml on disk), however other backends can be written. If we
went for shared-storage but not a shared db layer, we would just write a
new backend for that shared-storage.

The high-level services are the "query model" and "property model". A
query model is best though of as a result-set of a db query, which will
automatically update as things change (it also supports sorting and
"chained" query models). A property model collates the values of a
property in a query model, e.g. generates the list of Artists.

If we wanted to use Rhythmdb as the shared backend, I think that using
the low-level db abstraction bit would be best, with players optionally
using the high-level services.

Comparing Rhythmdb vs BMPx's db layer vs just sqlite will be difficult
until we agree what should and shouldn't be part of the shared database,
since they provide different capabilities.

> e) This should tie in with standardized cover art support

This sounds like a good plan. I haven't really looked at how any other
players implement art support, but I have some (unimplemented) ideas
about how RB could do it, properly supporting art-on-ipods, art embedded
into tags, art from podcats etc.

Probably the best thing to do would be to take one of the existing
implementations and make sure it can do everything we want it to.


James "Doc" Livingston
Proof that they're lusers who must die: they send spam saying "Restore
your sex life" even though they never told you to back it up. -- Anthony
de Boer in the Monastery

Attachment: signature.asc
Description: This is a digitally signed message part

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