[GSoC Update] Playdar Collection: Week 1

[Andy Coder]

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?

   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.

   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?

   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