Architecture discussion: the Collection Meta Framework Use/Misuse

[Bart Cerneels]

I'll group the discussion here, whatever we'll discuss on IRC should
be added here as well.

On Sun, Mar 2, 2008 at 10:20 AM, Nikolaj Hald Nielsen
<nhnfreespirit at gmail.com> wrote:
>> > Hmm, actually i was thinking about that. It's probably a bad idea to
>>  >  make everything fit the collection framework just so that we can
>>  >  resuse the collection view. So you might want to implement a custom
>>  >  view/model instead of twisting last.fm to fit the collection
>>  >  framework.
>>
>>  While that might be true in some cases, I really dont think it is
>>  needed here. The last.fm service service will, IMO, work just fine on
>>  a MemoryCollection, which gives us searching for free.
>>
>>  - Nikolaj
>>
> IIRC radio 2.0 is based on playlists, which means we'll end up having
> the same problem as in the shoutcast browser. And all those ideas
> about "expanding tracks that are actually playlists" sound like hacks
> to solve a problem that was created by using the framework, in
> particular the collection view, for stuff it was *really* not designed
> to do. While the framework could probably be extended (Bart said that
> he wants to integrate playlists into the Meta framework, and we should
> talk about that one of these days), the collection view is not
> designed to handle it, and should *not* be changed. The code is
> difficult enough, and we should try not to make it anymore complex.

I'll outline my reason for wanting integration of Playlists in the
collection framework:
 - Since playlists contain tracks, they will always be associated with
either a TrackProvider or a full Collection. (TrackProvider is a
Collection "Light" which mainly just implements trackForUrl)
 - PlaylistProvider is a laugh compared to Collection, just a few
playlist relate functions which can easily be added to Collection as
virtual stub functions.
 - PlaylistManager only contains a few "real functions" plus a few
convenience functions which can be easily moved over to the
CollectionManager.
 - Reusing the Capability system.
And last but not least:
 - Makes implementing Playlist based Services (shoutcast, last.fm,
etc) a breeze since they will all share the same TreeView, in this
case it would be the same treeview as uses in PlaylistBrowser.
PodcastCategoryView is an example of that.

>
> Maybe you could outline, better here than on irc, what exactly should
> go into the tree view of the last.fm service. If it's anything like
> the like the official client (i mean the tree view on the left), a
> custom view and model are a better solution.
Indeed, not everything maps well to a tree view. last.fm might be one of them.
Of course we can still make it a treeview of Meta::Playlists. Example:
Last.fm root
| - Personal radio
| - Neighbor radio
| - -Track #1 (if showing tracks before the radio is accessed it possible)
| - -Track #2
| - Custom radio
| - Similar artists (to current playing track) in an available collection
| - - #1 Artist - Track
| - - #2 Artist - Track
| - Global Tag Radio
| - - (these required sub playlists!)

An alternative to the global tag playlist situation is to have them
all in the top level, but that might become messy if there are many
tags.

Bart