[GSoC Update] Playdar Collection: Week 1

[Andy Coder]

On Sunday, May 30, 2010 05:03:54 am Maximilian Kossick wrote:
> 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.
> 

Any idea where to?  I thought shared/ sounded right initially, but 
JsonQt isn't used for utilities, which clashes with the README note in 
that directory.  I'm not sure if anything else seems appropriate.

 - Andy Coder

> >   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
> 
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel