Architecture discussion: the Collection Meta Framework Use/Misuse

[Maximilian Kossick]

On Wed, Mar 12, 2008 at 3:19 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> On Wed, Mar 12, 2008 at 1:48 PM, Maximilian Kossick
>
> <maximilian.kossick at googlemail.com> wrote:
>  >
>
>
> > On Mon, Mar 3, 2008 at 5:20 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>  >  > 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.
>  >  >
>  >  I just saw meta/DynamicPlaylist.h, and remembered that I forgot to
>  >  send this e-mail...sorry for that
>  >
>  >  I've got a few comments and questions regarding that class diagram:
>  >  It looks like you generated it from the existing sources. It does not
>  >  contain a class for smart playlists. Do you want to integrate smart
>  >  playlists (and dynamic playlists, although they are a special case
>  >  because they require a new TrackAdvancer) into the playlists
>  >  framework?
>  I would yes, they should be saveable and behave just like the other playlists.

Ok, but see the comment in my original e-mail. Dynamic Playlists wrap
a smart playlist (well, actually any other playlist),
and support accessing those playlists track by track. It simply does
not make sense for dynamic playlists to have a tracks() method.

>
>  >
>  >  Why is there a load(QTextStream) method in Meta::Playlist. Doesn't it
>  >  make more sense to put that into the implementation ctor?
>  Yes probably, this is the result of copy pasting from other code.
>
>
>  >  If we want to integrate smart playlists, Playlist::tracks() should be
>  >  made asynchronous.
>  >  I don't think we need prettyName. It does some magic if a file's tag
>  >  are incomplete, but I don't think that's a problem with playlists.
>  XSPF has title in it's metadata, so would a SQL implementation, yet
>  the standard name() might be the xspf filename or "SQL: ".
>
I didn't think of that. We need some kind of id for composite dynamic playlists.
How about renaming name() to id() and prettyName() to name() ?
>
>  >  What's the use case for retrievableUrl?
>  Drag and drop to outside of Amarok, i.e. copy to a folder by dragging
>  from the playlistbrowser. The retrievalbleurl would be a reference to
>  the Playlist. I'm not sure this will work since I don't know D'n'D
>  very much.

How about calling it url() instead. unless we have an url() method as
in Meta::Track (which shouldn't actually be called url(), but it's a
bit late to change that now), there's no need to call it
retrievableUrl().

>
>  >  And I'm not sure what advantage capability interfaces give us in this
>  >  case? We could add a Playlist::type method, which would allow us to
>  >  sort the playlists in the playlist browser
>  >  Or is grouping playlists in the playlist browser not what you want
>  >  Capabilities for?
>  No, for the same reason as in the CollectionTreeView, I want to keep
>  out implemetation details from specific Playlist versions (like SQL,
>  XSPF, webservice) from the playlistbrowser.

I still don't get it. What kind of implementation details are you
talking about? I don't think capabilities are necessary for stuff like
editing a playlist. Can you give a few examples what kind of
implementation details you'd make accessible using capabilities?

>
>  >
>  >  Plaese note that it does not make sense for DynamicPlaylist to inherit
>  >  from Playlist. Dynamic Playlist has to wrap a querymaker, and needs a
>  >  method to access the next track to insert into the playlist, not to
>  >  access all tracks.
>  >
>  >
>
>
> > _______________________________________________
>  >  Amarok-devel mailing list
>  >  Amarok-devel at kde.org
>  >  https://mail.kde.org/mailman/listinfo/amarok-devel
>  >
>