GSoC Update -- Playdar Collection

[Leo Franchi]

On Mon, May 24, 2010 at 11:56 AM, Ian Monroe <ian at monroe.nu> wrote:
> On Wed, May 19, 2010 at 8:27 PM, Andy Coder <andrew.coder at gmail.com> wrote:
>>    With the 'start coding' date approaching, and since I've been
>> awfully quiet lately, (mostly reading code and documentation), I
>> figured it would be a good time to compile and expose my thoughts and
>> progress regarding the project.  If anyone's got the time, I would, of
>> course, appreciate corrections anywhere I might be going down the
>> wrong path, I just need told about something I'm not yet aware of, or
>> I'm entirely off-base, (and opinions for any reason).
>>
>>    My time not spent reading [about] Amarok/Playdar code has mostly
>> been spent considering the various options for how the collection
>> should interact with Playdar:
>>
>>    Not really in the running at this point, but possibly worth
>> mentioning, is the use of Playdar's HTTP API.  This has the benefit of
>> being easy, since we only have to generate query URLs, access them,
>> and ask for results later at URLs generated with the query.  It would
>> also make it trivial to allow users to elect to use a Playdar service
>> on another machine, (even though that's not necessarily something
>> Playdar's meant for, it would work).  On the other hand, nearly every
>> other option would likely involve nicer code and possibly better
>> performance, without any apparent loss of functionality, (and maybe
>> even bonus features).  There's also a websocket API that works
>> similarly and would probably be just as easy, (maybe easier), but is
>> marked 'experimental' and doesn't seem to be a much better choice,
>> (though it would, presumably, perform better).
>>
>>    A more exciting option is spawning a Playdar instance in a
>> QProcess.  If this were the case, we'd have access to the Erlang
>> shell, and could invoke queries and deal with results however we'd
>> like.  When querying the collection, we could even resolve queries by
>> passing them to any existing Amarok collections that we can pass them
>> to, and leave out Playdar's local resolver to avoid having a spare
>> database.  The issues with this are that it's not nice when there's
>> already a Playdar instance and generating code and piping it into the
>> Erlang shell, while potentially powerful and interesting, seems like
>> it would get messy quick.  The programming language geek part of me
>> wants to do this, but the sensible part of me thinks there are better
>> options.
>
> I agree with your assessment, string parsing is yuck.
>
>>    Playdar.js, the JavaScript interface to the aforementioned HTTP
>> API might be a prettier option.  The big problem with it is that, as
>> far as I can tell, the whole JavaScript library would need to be
>> maintained within the Amarok source.  I don't know how general
>> feelings are about this sort of thing, but my instinct is to avoid
>> this sort of situation.
>
> I don't really understand this. How do you use a JavaScript library to
> interface with a process?

The Playdar.js lib is used to interact with the playdar server over
http, all the current playdar websites use it basically.

>
>>    Finally, there's the planned external script/binary API.  There
>> isn't much known about it at this point, but it seems like a
>> specification is due to be talked about soon.  Still, it seems to me
>> to be want we want to use.  It's also possible that this will be the
>> only option, (aside from working in the Erlang shell), that's intended
>> to provide support for browsing collections, which is an important,
>> (though probably not required: I think it could be done entirely on
>> the Amarok end to some extent), feature to make the project work as
>> planned.  Using Erlang code in C++, (and vice versa), isn't
>> particularly straightforward, but Playdar's local library resolver is
>> moving to C++, so it appears likely that it won't be an issue on a
>> Amarok side.
>>
>>    The rest of my efforts have been towards the planning of the
>> Collection.  My current inclination is to inherit from
>> MemoryCollection.  If things work out on the Playdar end with the
>> collection browsing support, I'm under the impression that the
>> behavior will be something like:  Amarok says 'what can you see,
>> Playdar?' and then Playdar starts spewing out content objects from
>> resolvers which support it, (probably just local and lan, in the short
>> term).  Adding these to a Memory collection should then be fairly
>> straightforward, especially since, as I recently discovered, jsonqt is
>> already included in Amarok.  I don't think MemoryCollection will let
>> me distinguish between, (and allow different actions on), content from
>> different sources, but, even though I think it'd be nice, Playdar
>> doesn't readily expose the actual location of results on principle and
>> for consistency, always providing a local http:// URL insead, so this
>> probably isn't something I should be concerned about.
>>
>>    If that goes as well as I think it should, the real work is in the
>> queries.  When new results are available, the intended behavior is to
>> add them to the tree view as it's filtered.  My understanding is that
>> adding them to the collection and the results list would do the trick,
>> but the addition of various results to partial queries (later filtered
>> out due to further user input) to the collection for the remainder of
>> the session may not be such a great behavior.  If I only returned them
>> as results and left them out of the collection, would they still
>> appear in the tree view?
>>
>>    My next step is opening up conversation on the Playdar end,
>> hopefully finding out more about API/collection browsing plans and
>> seeing what I can do to help things along.  And next week I should be
>> able to at least start coding something.
>
>
> Yep, asking Playdar what you should do is a good idea.

See the playdar list if people want to follow along :)

leo

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