GSoC Update -- Playdar Collection

[Andy Coder]

    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.

    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.

    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.

 - Andy Coder