On 21. 3. 2012 Bart Cerneels wrote:
> On Wed, Mar 21, 2012 at 00:06, Matěj Laitl <ma...@laitl.cz> wrote:
> > Project Goals
> > ========
> > This project will implement:
> > * track statistics synchronization between Amarok collections that
> > support
> > statistics; these are currently Local Collection and iPod Collection, but
> > the framework will be general
> > * Last.fm scrobbling from pluggable media players that support statistics
> > (iPods, currently) using the general framework from previous point
> > * ability to synchronize labels from Amarok to Last.fm
> > * ability to synchronize play counts, first & last played date from
> > Last.fm to Amarok collections (other way around is already implemented by
> > scrobbling) * GUI dialogue for performing the synchronization/resolving
> > conflicts
> >
> > Implementation
> > =========
> > Speaking about Last.fm integration, Last.fm provides rather nice RESTful
> > API [5] a subset of which is already used through liblastfm [6] library
> > in Amarok to submit (scrobble) currently played songs. I plan to reuse
> > this library and Amarok code dealing with it; the Last.fm API is powerful
> > enough to support all claimed features. There is already even Last.fm
> > on-line service Collection, but it focuses on playing Last.fm radio
> > streams and doesn't handle individual tracks. In order to implement
> > actual synchronization with Last.fm, user's Last.fm Library (that
> > contains relevant track data) can be represented as a new (invisible)
> > Collection or as special case in synchronizer, I have yet to decide this
> > design choice.
>
> I very much see the need for statistics syncing between iPod and SQL
> and similar. But I strongly object to a Collection for last.fm, even a
> hidden one. It's corrupting the architecture (Last.fm does not
> provide us distinct playable tracks, hence can not be a real
> Collection) and further complicates the codebase with various special
> cases. We've been suffering a similar mistake with Services already
> and want to avoid making it again at all cost.
>
> If all you really need for synchronization from last.fm to a
> Collection is metadata and a QueryMaker, I don't see the need for a
> Last.fm Collection, QueryMaker, etc. In order to keep it sane you'll
> have to execute the sync from the last.fm service anyway and have a
> config to select which Collections are synced (SQL as default). From
> SQL to last.fm is already implemented with scrobbling.
When giving it more thought, I must acknowledge that creating a fake
Collection would be a bad idea. Instead, and thanks to suggestions by Markey,
Sam & Christoph, Last.fm access could be accomplished through some kind of a
scrobbling service abstraction, for example:
class ScrobblingService
{
// mandatory:
virtual void scrobble( TrackMetaData track, QDateTime time = now() ) =
0;
// optional, constrained by API Last.fm provides [1] and performace:
virtual QStringList userArtists(); // ambiguity doesn't matter here
virtual QMultiMap<TrackMetaData, QDateTime> artistScrobbles( QString
artist
); // this seems to be the only way to get track first & last played datetime
virtual QStringList trackLabels( TrackMetaData track );
virtual void setTrackLabels( TreackMetaData track, QStringList labels );
virtual int trackRating( TrackMetaData track );
virtual void setTrackRating( TrackMetaData track, int rating );
}
The calls are are possibly long-running, so the interface should be either
asynchronous (thus more complex) or blocking-but designed to be run from a
non-gui thread (which I would prefer).
> Very good proposal in any case and I'm confident you can pull it off.
Oh, thanks for review and encouraging! I will update the implementation part
of the proposal; Also, I will reformulate it a bit to make clear that the
synchronization with on-line scrobbling services will not be Last.fm-specific.
(but this GSoC will still implement just the Last.fm backend)
Matěj
[1] http://www.last.fm/api/intro
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
