[GSoC Update] Playdar Collection Update 2

[Leo Franchi]

On Sat, Jun 5, 2010 at 6:32 PM, Andy Coder <andrew.coder at gmail.com> wrote:
> Time for another update!

Thanks for the 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...

Ouch, that sucks. Sorry dude :(

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

Sounds good. It shoudn't be needed if the player isn't being built.

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

I'll take a look at the code and get back to you if I have any ideas :)

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

Those both sound awesome! Those are exactly the sort of things i'm
excited to be able to do with playdar :)

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

leo

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