GSoC Update -- Playdar Collection

[Ian Monroe]

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?

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

Ian