Re: Common music database?

[Aaron Bockover <abockover novell com>]

Count me in!

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.

So just a few quick random thoughts:

a) a music database is something that should be per-user. 

b) one thing that should absolutely be avoided is another daemon.

c) DBus for notification, but should not be a hard requirement... if
DBus is there... great. If not, keep trucking.

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.

e) This should tie in with standardized cover art support

f) Must be portable, should be written in C; by portable I mean...
Windows, OS X, other Unixes. 

That's all I have right now as I'm really rushed, but I hope others
weigh in on this thread. Thanks sri!

Cheers,
Aaron


On Sun, 2006-03-12 at 12:30 -0800, Sriram Ramkrishna wrote:
> I was hoping to start a thread on a common multimedia backend for
> all the various players that we have.  On the table, we have rhythmdb,
> sqlite backends, and I think another using another embedded library.
> 
> 
> By in large, it seems that sqlite is the most popular in backends in terms
> of speed.  What would be nice is to decide on what would be an acceptable
> architecture for the backend and then move everyone to it.
> 
> This includes:
> 
> * Location
> * per user/per machine?
> * Architecture to allow notifictions of db changes
> * Speed
> * Name?
> 
> Hopefully, people will support this effort.  
> 
> Thanks,
> sri
> 
> 
>