Re: [Rhythmbox-devel] node tree structure

[Jorn Baayen <jorn nl linux org>]

So you think that it is bad that the library and iradio have a slighly
different structure? ;) Well dude, _of course_ they are different, they
are entirely different things! You can't expect one piece of code to
insert a song into the library and insert a radio station into the radio
station tree. They are different things, so different code, that is not
called code duplication ;)

You can easily query the flat list of all songs for certain properties,
returning a subset. This is exactly what rbnodefilter does, and
rbnodeview even supports setting a rbnodefilter so filtering works out
of the box. The artist/album-browser uses this filter too, by the way.

About SQL .. I can only hope you are not serious.

Cheers

On Sat, 2003-02-15 at 19: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:
> 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.
> 
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel@gnome.org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel