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. Cheers, 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