Framework for Playlists

[Jeff Mitchell]

Bart Cerneels wrote:
> 2007/8/16, Maximilian Kossick <mkossick at gmx.de <mailto:mkossick at gmx.de>>:
>
>     On Thursday 16 August 2007, Bart Cerneels wrote:
>     > Hi all
>     >
>     > I've been pondering how to properly manage Meta::Playlists within
>     > Amarok and I'm conflicted.
>     >
>     > Most Playlists will contain Meta::Tracks that come from a
>     Collection,
>     > and those Playlists should be provided by the Collection.
>     > When mediadevices are implemented as Collections (that is the plan
>     > right), they will deliver the Playlists populated with tracks in
>     it's
>     > own Collection.
>     > Dynamic and smart Playlists will not be created by a Collection but
>     > will use Tracks from the available Collections.
>     > These points suggest that adding Playlists to the Collection
>     Framework
>     > is a good idea. It seems to me there are technical hurdles though.
>     > Everything in a collection is tight together using Tracks, there
>     is no
>     > way of going straight from Artist to Albums for instance, you
>     have to
>     > use a Track. So unless we add a Meta::PlaylistList to every Track
>     > there is no easy way of querying for Playlists. There are other
>     > problems to, like PodcastEpisodes and Streams showing up in the
>     > CollectionBrowser unless they are specifically excluded.
>
>     Adding an albums() method to Meta::Artist is a good idea,
>     especially because
>     Meta::Album already has an albumArtist() method. Albums and
>     Artists are a
>     special case, I don't think it makes sense to add similar methods
>     to Genre,
>     Year and Composer because I can't see a real need for them...just use
>     QueryMaker instead.
>
>
> Seems like a good idea that won't harm anyone :) .
>
>     I don't think that the collection architecture is the right tool
>     for podcasts
>     and a stream directory like shoutcast (DAAP and stores like
>     magnatune are
>     different) You can write another framework which fits your need
>     better than
>     the current collection framework. You only have to be able to provide
>     Meta::Track objects, because the engine can only play those.
>
>
> I've already decided to start a new  framework just for Playlists. 
> Collections that also offer Playlists should subclass or create a 
> member of type PodcastProvider, DynamicPlaylistProvider, 
> SmartPlaylistProvider, StreamProvider, etc (note: have not created any 
> one of those). The default categories of Playlists are defined in the 
> PlaylistManager::PlaylistCategory enum. Other custom types can be 
> created by subclassing PlaylistProvider and registering it with a new 
> key (int) for a custom category.
> PlaylistManager allows other parts of Amarok (like PlaylistBrowser) to 
> request all Playlists of one of the categories that are offered by all 
> registered PlaylistProviders.
>
> More to follow soon.
>
> Stecchino
Please make sure you think carefully about playlist storage.  I can tell 
you one thing: it *must* be in the database, not on-disk (though of 
course import/export functions need to exist).  Especially if you want 
to do things like playlist syncing on mobile devices...you'll need 
specialized fields in the database for that sort of thing.

--Jeff