Re: [Rhythmbox-devel] node tree structure

[Colin Walters <walters debian org>]

On Sat, 2003-02-15 at 09:55, Jorn Baayen wrote: 
> May I suggest first learning the codebase before undertaking foolish
> changes like this? You'll make yourself artist/album/genre browsers a
> *huge* pain to implement, and plus we already have a very powerful
> filtering system. Have a look at rb-node-filter. Dunno, maybe it's only
> on HEAD.

Oh, I agree, it will make the browsers harder to implement. But one
problem with the current structure is that it kind of forces a different
tree structure for internet radio, which has no artist/album
information.  So the iradio view currently just creates a tree like
genre->songs.  This leads to code duplication.

Personally, I see the songs as simply a set (or a flat database).  Each
song has a set of properties.  Filters should be just queries on this
database for particular properties, which return a subset of songs. 
Then the main display should just know how to display a set of songs. 
The artist/album/genre browsers are then a simple way to change the
current query.

If things were structured this way, I think we could simplify the code
quite a bit, because then we could share a lot between the
library/iradio/CD backends.  The fact that iradio doesn't have
artist/album just doesn't matter.

Now, how to implement queries and the browsers efficiently though?  We
could simply iterate over all the songs and collect the set of
artists/albums/genres etc.  

But I have a better idea: we should use SQLite:
http://www.sqlite.org

This looks like *exactly* what we want.  It is a nice SQL system that
doesn't require an external server.  So now, the main browser view
simply becomes:
SELECT * from songs;
The artist view becomes:
SELECT DISTINCT artist from songs;
The genre view becomes:
SELECT DISTINCT genre from songs;
etc.

Now, making complex queries using Luca's dialog simply becomes a job of
constructing the right SQL.

Another nice thing about switching to an SQL-like architecture
internally architecture is that we will make it easier to support
multiple backends besides SQLite; there are a fair number of crazy
people out there who store their music information in an actual database
like PostgreSQL.  Oh, and also it allows for making the optimization of
not having all the song information in memory at one time; for people
with truly large amounts of music, this could be prohibitive.

I dunno, maybe I am wrong.  But I'll probably go ahead and try to
implement it, and if I fail, then at least I'll have learned something.