[GSoC Update] Playdar Collection Update 2

[Andy Coder]

Time for another update!

Unfortunately, I was distracted from most everything at the beginning 
of the week, since my car was broken into Monday, (only left it for an 
hour, in plain view of Memorial Day foot traffic in a small town, but a 
window was smashed and my GPS and satellite radio receiver were 
taken). Lame, time consuming and expensive to deal with, but it's 
over now...

Getting back on topic, I moved JsonQt into a new top-level directory 
named external/ as suggested and added a README.txt.  I also 
snipped the appropriate parts of the songkick engine's CMakeLists.txt 
and put them in a new one in external/, which I added to the include 
directories for the songkick engine, (both components build just fine 
for me).  I also added an 'add_subdirectory( external )' to the top level 
CMakeLists.txt in the 'if ( WITH_PLAYER )' section, but I'm not sure if 
this is necessary or appropriate, (thoughts?).

The Playdar backend structure has been simplified by scratching the 
old Controller/ControllerPrivate idea, and setting up a support 
directory with Controller.[h/cpp] and QueryObject.[h/cpp].  Both live in 
a new namespace, Playdar, and together provide the abstraction of 
Playdar's basic functions to methods of getting Amarok metadata 
objects by specifying search conditions.

I defined and implemented Playdar::Controller this week, providing 
status(), resolve( artist, album, title ) and getResults( qid ), (but 
forgetting getResultsLongPoll( qid ) which will probably be more useful 
in Amarok, it's on my list for this weekend).  The only problem I've run 
into is ensuring that the correct results get to the object that 
requests them.  As Playdar resonds to HTTP requests, Controller 
process the response and emits statusChecksOut(), qidReady( const 
QString& ), resultsReady( QVariantMap ), or error( ErrorType ) as 
appropriate.  However, objects connected to resultsReady() will get 
sent results from all finished queries.  My current solutions to this are 
using a separate Controller instance for each query or letting results 
get sent everywhere and assuming the receiving object will check 
.value("qid") in the map to see if it's theirs, using the correct results 
and disconnecting once they've got them.  Does anyone have 
thoughts on those two options or perhaps a better option that 
doesn't involve spewing results everywhere?

Some time was also spent considering context applet uses.  Aside 
from the straightforward search-and-play applet, I made some notes 
about a recommendations applet that takes suggested artist/last.fm 
tag/etc. data, selects some appropriate artist/[album]/title 
combinations and tries to resolve them, displaying any found tracks.  I 
also scribbled about an 'Alternate Versions' applet, which would 
attempt to find different recordings of the currently playing track.

This weekend/next week, I'm planning on finishing Playdar::Controller, 
writing tests for it, and working on Playdar::QueryObject, so there will 
be a usable interface to Playdar from Amarok before going on to 
make use of it in the collection and such.

Finally, my changes can be seen in the playdar_collection branch of 
[0].

 - Andy Coder

[0] git://gitorious.org/~andycoder/amarok/andycoders-amarok-
clone.git