Architecture discussion: the Collection Meta Framework Use/Misuse

[Maximilian Kossick]

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.

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

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

>  >  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
>
>
> _______________________________________________
>  Amarok-devel mailing list
>  Amarok-devel at kde.org
>  https://mail.kde.org/mailman/listinfo/amarok-devel
>

Max