[GSoC Update] Playdar Collection No. 3

[Andy Coder]

The past week has been spent working on Playdar::QueryObject, which uses a 
Playdar::Controller to communicate with Playdar, and provides a (hopefully) 
useful Amarok-side interface for setting up queries and getting results.

One issue that may need some further consideration is how a QueryObject would 
best get results from Playdar.  Playdar provides two options, getResults, 
which immediately responds with a JSON object that contains information about 
the query as well as the results found so far, if any, and getResultsLongPoll, 
which waits to respond until either the query is solved or the 'target time', 
(length of time in which a query would have been solved if it was solvable), 
of all resolvers has passed.  My current approach is to invoke getResults as 
soon as Playdar has acknowledged the query, and, when processing the response 
later, invoke getResultsLongPoll if the query hasn't been solved, noting in a 
private member bool that we did so to avoid doing it again.  The thinking here 
is that results on the local machine are ready fast (<30ms), and would then be 
available for use through the getResults call right away, but if we need to 
source the track elsewhere, it's worth the wait, so we invoke 
getResultsLongPoll.

The other point of concern is where to leave the responsibilities of handling 
Track/Artist/Album/etc. objects.  QueryObject provides a constructor and a 
setter to initialize query options with any Meta::Track object, which is 
fairly straightforward, and would be handy if our goal with a query is to find 
alternate results for the current track or to find a fresh url for a currently 
unplayable track.  If QueryObject intends to provide results as Tracks, 
however, it seems to get messy.

The main issue in this case is what to do about the other metadata objects 
besides the track.  One option would be to make new albums and artists for our 
results, but that seems like it would cause problems down the line, especially 
in the collection components.  The other thought I had is to either make 
QueryObject only provide data as strings and assume the object using it will 
know what it wants done, (probably a safe choice, but makes QueryObject seem 
less valuable), or to require a Meta::Track and QueryObject could assume 
control of it and update it directly as results come in, (but this complicates 
result lists that source a single title from several different albums).

Regardless, I've just about got things that may actually work, so I'm 
determined to get started writing some tests this week.  On the implementation 
front, working out PlaydarMeta seems like a reasonable next step, (and may 
have to precede tests, depending on how much QueryObject actually depends on 
it once decisions are more final there).

 - Andy Coder