github twitter linkedin email rss
Tomahawk and 7digital
May 23, 2011
5 minutes read

### Introduction

Tomahawk is a very interesting project - it defends that just because you have a music download or streaming service you should not be required to use the same service’s player - it’s the do one thing right principle or single responsibly applied to business.

It has multi source content resolution which means you might have several sources to your music, local hard drive, stream service, your cloud drive and many more.

By using a standardised protocol you can access these different sources and manage them by using time out and weight specifications so that when you have a playlist you’ll get the best experience available from all your services.

Unfortunately I was unable to get a working demo, the state of the player at the moment is not advanced enough to be easy to integrate with a already formed and more stable as 7digital’s and in the next points I explain this in more details.

API vs Resolver

There are three main ways to get information into Tomahawk, to implement the Playdar API, make a page easy to scrape for content or to create a custom resolver for a new API.

Because we do not implement Locker search and we need some sort of authentication it wasn’t feasible to get the API working so the choice had to go to a custom resolver.

### Development and debugging

The player is still quite recent, it’s current version is 0.0.3 (development version is 0.1) and most resolvers seem to be only available for 0.1 which made me spend some time trying to make resolvers work that were not supposed to work at all.

The resolvers are language/architecture independent but most development seems to be on Linux and Mac OS with only some smaller manual testing for Windows - the resolvers could be ran in any language but because #! does not work on Windows it is seen as a choice between JavaScript and compiled plug ins.

It didn’t help that some of the resolver demos didn’t work out of the box, they had bugs in them and there are no debug flag in the compiled player - which means I had to hunt down issues from within javascript IF it worked.


The customer resolver calls two methods in JavaScript - there is a initialisation and then a search query for each track every time a play list loads.

Because our locker does not have search this means it would hit the API locker endpoint a lot - this could be answered by caching the locker and doing searches in the cache data every time a track is called but who would handle this caching and searching? Is it Tomahawk’s responsibility? Is it a new 7digital service? And how to handle cache invalidation? How long would the first hit take to fill up the cache and is that a good user experience?

After speaking with a few Tomahawk developers I had the idea there is a locker resolver in progress which would get a locker dump and use that for the resolution - that seems like the easiest way to do it on our end but we still need to have a limited number of updates.


At 7digital all the API consumer need their own API key and we always authenticate/authorise consumers with OAuth 2.0 so this would be mandatory.

A lot of the resolvers will have it easier here, they work with free or accessible content (i.e. Youtube, Soundcloud) so a regular search query will give them the results they need without problems.

In our case we need to compare with resolvers that have authentication, again there was a lack of documentation about this and had to go through the existing resolvers to find how this was being done.

Spotify resolver (which was built from the ground up in C++) is using a regular API key which is hard coded in the plug in - they encrypted the communication but this is not user specific.

The only example using OAuth I found was Twitter which uses SIP and is not a content resolver but integrated into the actual player… But even here I found a problem, the Key and Secret for Twitter’s consumer is hard coded into it’s plugin - as the application will also have the user’s login and password for twitter this could end up badly.

So the options are - have an API consumer for each user (this makes no sense on the way it is supposed to work) or have a middle service to handle user authorisation/authentication which is encrypted and will represent the API consumer - in our clients this is usually the secure browser connection plus session information or their own platform.

### Work in progress

Out of curiosity I did implement a variation of the Playdar API that grabs the whole locker and gets the API end user token and secret in the URL to authenticate the user.

The user would still needs to access our authenticate page to grant Tomahawk access to the locker and write down the token and secret in the resolver.

Unfortunately I couldn’t get the JavaScript to work but I blame this on my lack of expertise with JavaScript and being hard to debug from within the player with just Fiddler and some alerts.


In my opinion a 7digital locker resolver for Tomahawk will be great for both but it is too early to implement this or it would be too much work (not something for the two days I had for this).

We would need a middle service that talks to 7digital API, caches lockers, provides secure end user authentication/authorisation, does optimised locker search for the number of hits we would expect and a clever way to access the Authorisation page so the end user gives Tomahawk permission to access the user’s locker and give the resolver these keys.

All of this would be used by a JavaScript plug in called from the player which will probably have it’s own limitations and no way to debug..

Back to posts