GSoC: Distributed Collections : Amarok

As part of Google Summer of Code, Ive recently applied for the KDE project(Amarok) for an idea which i had really wanted to implement for a long time. I have put a lot of effort into the proposal.Lets hope everything turns out for the best. Here is what the proposal looks like:-

Greetings!

The distributed collections project aims at implementing the capability in Amarok to browse/search/play music over Amarok instances on a LAN/Internet. Once implemented it will :-

  • Allow automatic discovery of Amarok Instances over a LAN
  • Provide Amarok the ability to query remote Collections
  • Provide an API to expose Amarok Collections to 3rd party applications
  • Allow creation of Master Collections distributed over a number of remote collections
  • Provide feature for playback of remote music

NOTE:Ā  It is a common API to serve the needs of querying remote Amarok collections and Ampache Servers. Also, servers like Magnatune.com can also use it to expose their music collections.

Motivation

Lets say, my friend working at the office or lab (somewhere remotely) has a collection of music that interests me. I would naturally love to go through his collection and copy to my collection, the music that I like. Rather than manually sharing it or physically copying it, the most convenient solution is to provide a feature in the media player to access his music collection in single click. Doing so provides transparency as he can access remote collections as if local to him. Amarok currently does not have support to query remote collections and such a feature is not offered within any media player currently. Addition of such a cool feature would definitely increase the popularity of Amarok dramatically. Though the Ampache API offers a similar functionality with Amarok as a front end to access music from its servers, the API is limited in functionality right now. Thus, a new API with extended functionalities would be beneficial to the Ampache community as well. In exposing the collection of Amarok, third parties applications offering music services can use this information understand the music tastes of the user, and provide better services. I strongly believe that implementing this feature could open up new avenues and revolutionalize the way music is shared.

Implementation Details

  1. The Avahi framework can be used for the auto discovery of Amarok Services. I have gone though the code samples in the repo. There are two major tasks:-
    • Implement a Avahi Server to publish the service over the LAN
    • Implement a Avahi Client to browse for services over a LAN
  2. Implement a REST API to access Amarok Collections. The Request is in the form a HTTP(GET/POST) request and the response is an XML document. This can be modeled on the lines of the existing Ampache(ampache.org) XML API with a few extensions:-
    • Use libmicrohttpd as a lightweight HTTP Server to handle GET/POST requests. It provides support for SSL/TLS using libgcrypt
    • Extend the Ampache API to handle multi-level queries. Right now the Ampache API is able to filter only one field at a time. Example of a multi-level query isALBUM is of GENRE:rock
      OR
      ALBUM contains ARTIST:bloom
      AND ARTIST starts with “foo”
      AND song name contains “bar”
    • Implement a Client taking in search parameters from the user(from front end), encode the query and pass query to the remote server. The response can be obtained asynchronously using the KIO framework, and parsing the XML files be done by the XML parsing libraries present in Qt.
  3. Create the front end with Qt
    • Add an extra option for “Remote Collections” in the media sources of the Collection Browser
      • When Clicked, the browser shows the list of available hosts to connect to. (using Step 1 as back end)
      • Clicking on a host allows the user to query(search) its remote Collection using the Query Maker. The Queries have to be encoded into HTTP requests.
      • Clicking on a Song enables local playback over http
      • Add a “Import into local collection” option

Tentative Timeline

Until May 1st
Since there is still time before the chosen student applications are announced, I would like to use this time to write simple KDE applications in C++ using Qt and submit a quality patch to the Amarok codebase. This would enable me to use the “getting up to speed” time better.
 May 1st - 10th
The Community Bonding Period. I would like to get a hang of the Amarok code base, hang around the IRC to know the community better and discuss with the mentors – Nikolaj and Karl about scheduling weekly code reviews and discussions.
 May 10th - 20th
I would like to start working on the design of the new API and finalize it through reviews and discussion with Karl Vollmer(lead dev of Ampache)
May 21st- 31st
Get the support for the HTTP server(libmicrohttpd) up and running, implement a few main methods of the API and test it out.
 June 1st- 15th
Complete the implementation of the new API.
June 15th-30th
Implement the client to access remote collections(Step 2 part 3). Complete the documentation of the API, and write tutorials on accessing remote Amarok collections. Get existing code and documentation ready for the midterm review.
July 1st - 10th
Check out the documentation on the avahi-client API and write the Avahi Client/Server backend to publish/browse services. Also, integrate it with the front end using the avahi-qt adapter for Qt/KDE.
July 11th-30th
Make the Remote Collections front end:- Add the appropriate GUI elements wherever necessary(as described in Step 3). Integrate the front end and back end, returning results of the query on remote collection in the collection browser. Ensure playback of media over http.
 August
Pencil down date approaches. Clean up the code, do a through testing of modules for bugs and fix them. Complete pending documentation and get the code ready for integration with the repository.

About Me

I am a final year student pursuing my bachelors in Computer Science at Amrita University, India. I have 3 years experience working with GNU/Linux and KDE and have been a FOSS supporter ever since. As a way to apply theory through practice, I wish to apply my programming skills and contribute to an open source project. Amarok, being my favourite music player was my obvious choice. My past open source experience involves contributing small patches to the Open Solaris and Haiku code base. I have given a talk at a national FOSS conference, FOSSTER ’09 on “Customizing a GNU/Linux distro”. I am also the core member of the LUG at the campus, foss@amrita and also part of the Indian Linux Users group, Chennai (ilugc). My experience with programming contests such as ACM-ICPC have given me good problem solving skills and the ability to learn and adapt quickly to different programming languages. I also believe in good coding practices and conventions and it can be seen by my projects hosted at Github.

I have a sound knowledge of C++, but limited experience with Qt. Hence, I am working on a Qt tutorial and submission of a patch, which i am confident of completing soon. I am a fast learner, and am confident of picking up the necessary skills quickly. I would like to continue to contribute to Amarok and the KDE project even after Summer of code and undertake responsibility for the maintainence of any code contributed by me.

4 comments on “GSoC: Distributed Collections : Amarok

  1. Y’know, Playdar does _almost_ the same thing as this idea (with great efficiency in resolution). But it works with a directive of you wanting to listen to something, not browse and play generally – although that way is directly possible too with its API.

  2. I was able to display the collection of a remote Amarok instance. But it still needs finishing touches to be able to integrate it into the main repo. I am trying to find time for it. This is one feature I myself have been dying to have for a long time šŸ™‚

  3. Hi, this is very impressive and very interested as well. I suggested the implementation of the same in PMC(the project on which I’m currently working on) but they didn’t want it to be implemented at this juncture.
    Has this been integrated into the amarok codebase ? I’m aspire to write a similar proposal for my idea šŸ™‚

    Thanks.

Leave a comment