[GSoC Update] Playdar Collection: Week 1

[Maximilian Kossick]

On Sat, May 29, 2010 at 7:56 PM, Andy Coder <andrew.coder at gmail.com> wrote:
> Hey folks!  It's update time!
>
>   Although I'd been hoping to get some code written this week, I've
> mostly just collected pages of notes, scribbles, and sketches, but I
> did set up a proposed directory/file layout, (and the object layout it
> implies), which looks like:
>   in src/core-impl/collections/playdarcollection/:
>      PlaydarCollection.{h,cpp}
>      PlaydarQueryMaker.{h,cpp}
>      PlaydarMeta.{h,cpp}
>      controller/
>      controller/PlaydarController.{h,cpp}
>      controller/PlaydarControllerPrivate.{h,cpp}
>
>   Still missing here are places to provide capabilities.  It looks like
> other collections put these in their base directories, but my first
> thought was to have a capabilities/ subfolder.  Any opinions?

A capabilities/ subfolder sounds neater. Don't forget to put your unit
tests into tests/core-impl//collections/playdarcollection !!

>   Regarding PlaydarCollection, I think it makes sense to use a
> MemoryCollection, much like we do for DAAP.  What I'm not clear on,
> however, is where the populating of the collection should be
> implemented.  Is there a reason not to start the process from
> PlaydarCollection's constructor?
>
>   I expect PlaydarQueryMaker to use a MemoryQueryMaker to query
> the MemoryCollection, while asking Playdar to resolve queries and
> augmenting the results list with any results as it's informed of them.
>
>   PlaydarController implements an interface to Playdar that makes
> sense in Amarok/Qt world, so that we can initiate queries as Meta
> objects and wait for a signal that there are valid result URLs.
> PlaydarControllerPrivate is used like a d-pointer, and directly
> implements the functionality of the Playdar API, (status, resolve,
> get_results, and eventually something to fetch a collection's
> members).  This way, future API changes primarily affect
> PlaydarControllerPrivate, and the only reason PlaydarController itself
> should have to adapt is to add new functionality.
>
>   For PlaydarMeta, MetaStream may provide at least most of the
> needed functionality.  None of the Playdar result URLs that I've given
> to Amarok as streams so far have had any metadata troubles, at
> least.  There's the (extremely annoying if it happened in a situation
> where we new what track/artist/album to expect) behavior where a
> stream is initially a URL until it's playing/been played and the
> metadata has been fetched from the stream, but providing an
> alternate constructor would probably do the trick.

You will definitely need to read track metadata using the Playdar API.
MetaStream will generally not provide metadata until the stream is
played. MemoryQueryMaker excepts all Meta objects to have the correct
metadata at all times.

>   A more interesting problem to consider with PlaydarMeta is that, if
> Playdar has been stopped and restarted since a track was created,
> the playableUrl is no longer playable.  This is most noticeable if there
> are Playdar streams in the playlist, and the systems restarts,
> resulting in unplayable members in the playlist when Amarok is
> opened again. However, since it's likely that a new Playdar instance
> knows where to find the track, (since the old one did), we can get a
> new URL.  A 'Resolve' capability could be exposed through the right-
> click menu easily enough, but it makes more sense to me to do this
> automatically if we need to.  I'm not sure I can use the existing
> MultiTrack functionality for this directly, but the solution may at least
> be similar, using a 'Resolve' action as a fallback if the existing URL
> doesn't work out.
>
>   Finally, I noticed that JsonQt is in the Amarok source,
> (src/context/engines/songkick/JsonQt).  I'd like to use this, since
> Playdar responds in json and may accept it in the future.  Should I
> include it where it is now, or work out another arrangement, like
> moving it somewhere less component-specific?

Move it somewhere less compnent specific please.

>   For the next week, I'm planning on playing fill in the blanks with the
> above files, making more notes, possibly being a bit more intrusive
> when trying to get information from Playdar folks, and throwing
> together a quick little test with JsonQt and various JSON responses
> Playdar generated yesterday so I can tell exactly what sort of
> QVariants I can expect to be working with.
>
>  - Andy Coder
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>