GSoC Update -- Playdar Collection
Leo Franchi
lfranchi at kde.org
Tue May 25 00:10:02 CEST 2010
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
More information about the Amarok-devel
mailing list