Architecture discussion: the Collection Meta Framework Use/Misuse

[Bart Cerneels]

On Mon, Mar 3, 2008 at 10:05 AM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> On Sun, Mar 2, 2008 at 11:34 PM, Nikolaj Hald Nielsen
>  <nhnfreespirit at gmail.com> wrote:
>  > >  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)
>
>  Anything which uses tracks is somehow associated with a TrackProvider
>  or a Collection. I'm not quite sure what you mean by this.
I mean that a PlaylistProvider is always associated with Collection or
TrackProvider. It depends on them for creating the Meta objects and
implementing 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.
>
>  Not all collections support playlists. So why do you want to add
>  playlist related methods to the
>  collection interface? And what would those methods do?
Use multiple inheritance or m_playlistProvider in those Collections
(or Services) that can provide Playlists.

>
>
>  >  >   - 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.
>
>  I'm not sure why we'd want to do this. The Capability system was
>  stolen from Solid to get MetaProxy to work properly and to simplify
>  the the Meta inheritance tree, while still
>  making it possible to use methods which are not defined in the main
>  Meta classes.
>  What's the use case for adding the Capability system to playlists?

Your right, we might be able to do without if we create a seperate
view for each Meta::PlaylistCategory. Unless we wont to reuse
PlaylistTreeView's, then we need Capability again.

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

Bart