Architecture discussion: the Collection Meta Framework Use/Misuse

[Nikolaj Hald Nielsen]

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

I agree with these points.

What in general concerns me though, is that if the collection
framework is deemed off limits to playlists and streams ( and any
service that provide these ), we demote a lot of content to being
"second class citizens", and in doing so encourage parallel
implementation of similar features. And I have not yet seen a
compelling reason to do this.

>  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!)


I don't think you are allowed to see upcoming tracks. But I might be wrong.

- Nikolaj