Architecture discussion: the Collection Meta Framework Use/Misuse
bart.cerneels at kde.org
Mon Mar 3 15:22:24 CET 2008
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
> > > - 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
More information about the Amarok-devel