Architecture discussion: the Collection Meta Framework Use/Misuse

[Bart Cerneels]

In a different thread with cryptic title
extragear/multimedia/amarok/src/servicebrowser/lastfm, Maximilian
asked for a class diagram of the current Meta::Playlist classes. Here
they are:
http://users.telenet.be/shanachie/files/amarok/Meta_Playlist.pdf

These are only the Meta Classes, the rest is best explained functionally:

PlaylistProvider is equivalent to TrackProvider, it just implements a
few functions to register an amarok subsystem to PlaylistManager as
something that delivers Meta::Playlists of a certain Category.
PlaylistManager::PlaylistCategory is an enum for the build-in types
but a function allows plugins or scripts to register a dynamic
PlaylistCategory for playlsit types that don't fit any of the standard
categories.
PlaylistManager can be queried for Playlists of a certain type,
grouping all Meta::Playlists from all subsystems of Amarok.
An example:
    The category PodcastChannel is delivered by the Local
PodcastCollection but also by an iPod MediaDevice.
    So we can add Podcasts to Local or to iPod transparently.
    Using a system similar to CollectionLocation the Local and iPod
Podcasts can be kept synced or we can copy PodcastChannel
subscriptions from local to the iPod.

You'll notice familiar concepts similar to trackProvider -
CollectionManager - Meta::Observer CollectionLocation return in the
Playlists.

Hope this helps to understand the Meta::Playlist system.

On Mon, Mar 3, 2008 at 3:22 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> 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
>