Re: [Rhythmbox-devel] node tree structure

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;
> 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.

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


/Bastien Nocera

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/ printf ("Oh my %s\n", preferred_deity);
Segmentation fault

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]