[GSoC Update] Playdar Collection No. 3

[Maximilian Kossick]

On Mon, Jun 14, 2010 at 2:21 PM, Leo Franchi <lfranchi at kde.org> wrote:
> 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.

QueryMaker's newResultReady signals may be emitted multiple times, and
queryDone just once I doubt that all client code using QueryMaker is
handling that correctly though.

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

One important point to note is that the collection has to return the
same Meta object across multiple queries. So you should find a place
where your code could say "hey, i've already seen this track, let's
reuse the Meta::Track object that already exists".

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