Some intresting findings regarding Spotify desktop clients

My story is regarding the graphical user interface of the Spotify client, something that there is a certain silence around.
The implementation has no any public mention from the company but when extracting the resource folder in the app directory (resources.zip on PC), you find a folder called ‘views’ with a bunch of XML files. This would be obvious but there is intresting things lying there. The XML file contains code that could be refered to an Mozilla XUL implementation, but this seems not be the holy true. The markup is mixed with mystic preprocessor codes, and the preproccessor snippets contains script. From the app license view, you can see Spotify uses Lua, and there is no official explaination further about it, but it seems to be ackward the preprocessor directives contains segments of lua code.

 

I have never discovered this kind of markup, especally not with preprocessor chunks in a client side application, telling us this is not piece of a common framework. When trying to contact spotify regarding what this code is for, they refuse to explain what kind of frameworks they use. But the code is extremly intresting, since we don’t usually see preprocessor code in a client-side app resource file. Also, the markup, that looks like HTML is pretty mystical, some chunks seems to be somewhat like HTML, but name of attributes and tags may sometimes feel surrealistic. For example, there is a set of CSS stylesheets but they violates most of the rules W3C has set up.
I was very intrested of the piece and has spend the latest days on creating an own implementation of that framework as a .NET library, completely from ground in an augemented manner, without any documentation or further explaination of what components involved, I figure out that this is an special integration between Spotify hermes protocol and the user interface, and the choice of this very avant-garde manner is that the interface could be updated more often without having to dig in DOM trees because the UI refreshes like a web page upon receiving a new hermes notification in a certain view, like playlist, artist or search. Another mystic thing is that if you update the Linux client while running Spotify, the views become corrupted and you see the most text be replaced with either tokens or ${attt} attributes, which tells us this case is mostly the true. In end of last year, Spotify introduced the apps platform, and began moving onto using WebKit and Chromium for further features. As I’m very enthusastic in technology, especally Spotify, I were on a job interview over skype, where I asked about Spider, and they said it was an old framework they did in the beginning and I was schooled on a meetup in Stockholm that this was the old solution before they introduce apps. There is however a document on the internet, a theis from chalmers who indicating that Spotify avoided to use existing layout engines for their desktop clients as they wished to keep the amount of memory in use low and safety threading.
What makes me so obsessed with finding the truth about the views in the spotify directories is that Spotify behaved extremly fast in earlier version. In the earlier time, I had a crappy Acer Laptop and Spotify worked like a charm, while ALL other software did freeze each time. At that time (2009) I just felt Spotify were like Songbird (which gone diaster) but were so quick and response. The Spotify interface was in their first version, one of the most response apps I ever have experienced in this reality. I can’t remember any time when Spotify freezed or the UI component did lag. But ALL other software did it, Spotify did never. This make me very intrested in finding out how the views resource are built, in order to make my own programs that could be so response.
I assume from my oral communication with people at Spotify (I’m a loved used there, have been there two times on their HQ on personal visits), the rendering and layout engine is a part of a hevily protected part of the software, and on several pages, they state that they cannot reveal anything about the client to minimize the risk people could download the music for free. But I wonder how this layout subsystem could help folks piracy, but It might be as the XML/Lua preprocessor stuff seems to work at a fairly low level, although the XML looks like Mozilla’s XUL tags. Mozilla XUL behaved so slow, this is another reason I really had a burning intrested to get this known.
As the chances is none to get aware of the truth behind this engine, as this is a part of protected areas of the software, I began coding an own implementation of the engine in .NET, with only the resource directories as my documentation. I plan to make some certain differences between the Spotify and my implementation to undergo any kind of legal claim. The name spider has not been announceed at all, and while I was scary to do kind of infringation, I told about my developments at a meetup and they wished to have a look at my github. 🙂
Although Spotify is not hiring .NET developer at this point, as they use C++ and Python, it might not be impossible I someday become an employee there.
Sources
Using webkit in Spotify
C# Library from krikelin (my avatar on GitHub)
Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s