[GSoC Update] Playdar Collection No. 3

[Leo Franchi]

Thanks for the update!

On Sat, Jun 12, 2010 at 6:44 PM, Andy Coder <andrew.coder at gmail.com> wrote:
> 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.

I think returning a result immediately, and then also updating with
new resolved results makes the most sense---the user wants immediate
feedback, but also to be updated of new results.


> 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.


I am not super familiar with the Meta code, but logically it makes
sense to me to return Meta::TrackPtrs rather than string data. Seems
like avoiding Meta objects would be throwing away the benefits we have
from the Meta system---and the calling code would always have to
convert to a Meta pointer in order to do anything (say play, or put it
in a playlist, etc).

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



-- 
_____________________________________________________________________
leo at kdab.com                                 KDAB (USA), LLC
lfranchi at kde.org                             The KDE Project