[Rhythmbox-devel] State Of The Rhythmbox (3)

[Colin Walters <walters verbum org>]

First, for those tracking the arch tree, I'd like to say that the
rhythmbox--cvs--1.0 branch is no more.  Instead, I am going to simply
commit to keeping --mainline and the GNOME CVS in sync.  You shouldn't
have been using --cvs really anyways.  This keeps things simpler, plus I
can use this nifty script that Miles Bader wrote to sync his GNU Emacs
arch<->CVS tree.

Now, more interestingly: The first pass at RhythmDB is done.  It's a not
insubstantial amount of code:
walters@columbia> wc -l *.[ch]
   831 rhythmdb.c
   244 rhythmdb.h
  1686 rhythmdb-tree.c
    57 rhythmdb-tree.h
   192 test-rhythmdb-indexing.c
   487 test-rhythmdb-query.c
   322 test-rhythmdb-simple.c
   128 test-rhythmdb-tree-deserialization.c
   159 test-rhythmdb-tree-serialization.c
  4106 total

It has almost 40 regression tests (which it passes), and I've run it
through valgrind a number of times and squished all the errors (and
memory leaks) that brought up.  So I'm fairly confident in its
correctness.

How fast it is is still unknown.  I would be quite shocked if it was
slower than RBNode, but it is possible - we are making a tradeoff with
constructing a set of pointers to the nodes for each query, versus
re-filtering them each time.  But I am pretty sure it will be faster
(especially for larger collections), and it should definitely use less
memory.  I think in general, we will be speed-bound by GHashTable.

However this is only half of the game - the other half is converting
Rhythmbox to use it.  Here's a tentative plan:

* A plan for refactoring Rhythmbox to integrate RhythmDB

** Shell will create/destroy the database object

** Library takes database object, creates new thread to refresh metadata

** Morph RBIRadioBackend into the trival class RBIRadioLoader

** Turn RBNodeView into RBEntryView
*** RBTreeModelNode goees away
Instead, just add a bunch of columns into an RBTreeView, but set
the column_func to get the correct value

Yann - you seemed interested in working on this last bit, any progress?

I am a bit torn as to whether or not to commit RhythmDB to --mainline
(and therefore the GNOME CVS). Right now it isn't very intrusive with
the rest of the tree, but it shortly will be, and if we plan to make a
0.5.4 release then this will make things a lot more difficult.

But if I continue rhythmdb in its own arch branch, then only arch using
people can help out.  Hm.  Probably the best thing would actually be to
commit what I have now so people can see how it works, and then do all
the intrusive work in the arch branch, and then merge it over once it
sort of works.

Finally, one general observation: mostly this conversion will involve
deleting code.  Isn't that a beautiful thing?