Re: [Rhythmbox-devel] node tree structure
- From: Bastien Nocera <hadess hadess net>
- To: rhythmbox-devel gnome org
- Subject: Re: [Rhythmbox-devel] node tree structure
- Date: 17 Feb 2003 10:13:04 +0000
On Sat, 2003-02-15 at 18:20, Colin Walters wrote:
> 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:
> 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;
> 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.
We already thought about using a database as the backend (about a year
and a half ago :). We would still need to avoid any kind of
configuration to the user, and the easiest would probably be to use
gnome-db (mergeant, or whatever it's called these days ;). I'm still not
sure about the performance though...
#2 0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
] [Thread Prev