[Amarok] bc4fc15: APG is never going to implement PlaylistProvider

[Bart Cerneels]

Wrong on all accounts.
It wouldn't have hurt to discuss this with me before declaring this in
such a public manner you know. Now you're just demonstrating your
ignorance.

The documentation for trackCount() clearly states that when tracks
have not been determined yet -1 should be returned (and that is the
default).

PlaylistObserver is the way to get dynamically generated tracks. At a
call to tracks() you basically start resolving and call
Observer::trackAdded() for each one generated.

You don't how to implement addTrack() and removeTrack() if it doesn't
fit with the providers functionality.

On Fri, Sep 17, 2010 at 20:44, Soren Harward <stharward at gmail.com> wrote:
> commit bc4fc152d461a7f3af6c393bd85ee8ad82d49fe6
> Author: Soren Harward <stharward at gmail.com>
> Date:   Sat Aug 28 18:31:09 2010 -0400
>
>    APG is never going to implement PlaylistProvider
>
>    The problem isn't implementing the APG as a PlaylistProvider.  That's
>    pretty easy to do.
>
>    The problem is implementing APG Presets as a Playlist, which is the
>    defined behavior of the PlaylistProvider.  The single biggest
>    showstopper to this implementation is the fact that Playlist::tracks()
>    is defined synchronously, while the ConstraintSolver in the APG operates
>    asynchronously.  Thus, either the Playlist class would have to be
>    substantially rewritten to operare asynchronously, or the call to
>    Playlist::tracks() would have to block until the ConstraintSolver
>    finishes.  Neither of these is an attractive option.
>
>    Further problems (though not as dire) occur with the addTrack() and
>    removeTrack() functions, and the trackCount() function.  And having an
>    Observer of an APG-based Playlist is just pointless because the APG
>    never adds or removes tracks, unless it generates a completely new
>    playlist.
>
>    So as far as I'm concerned, this issue is dead.  The APG will not ever
>    implement a PlaylistProvider because it just doesn't fit the design
>    paradigm.
>
>    CCMAIL: bart.cerneels at kde.org
>
> diff --git a/src/playlistgenerator/TODO b/src/playlistgenerator/TODO
> index 1727bb1..06f503c 100644
> --- a/src/playlistgenerator/TODO
> +++ b/src/playlistgenerator/TODO
> @@ -3,7 +3,6 @@ Backend:
>   from XML, and put XML in Constraint superclass
>  - monitor APG patent: US 11/994425
>  - actually have the speed/accuracy slider do something
> -- implement a playlistprovider (per Bart on merge request)
>
>  Constraints:
>  - fix preventduplicates: the delta functions are kinda broken
>