Hi Simon, Thanks for the detailed response. After googling around a little, it would appear that Spotify had been supporting at least two (perhaps several) protocol revisions for a while, but they have recently removed the deprecated protocol version that despotify relied on.
While I could probably figure out some way to make the new protocol work, it would be more difficult to reverse engineer the new protocol than to use a different client library to link to spotify in the mpd support. One option is libspotify, from Spotify themselves. libspotify advantages: * Will *always* work. Although extremely old versions of the library may stop working if they remove support for protocols that will be deprecated in the future, the fix is just to update to the latest version of libspotify. Historically, major revisions of libspotify have only resulted in relatively minor code changes to support the new protocol, such as adding a parameter to a function, usually an optional parameter that you can pass NULL to and it'll continue to work. I have experience upgrading old code using libspotify to a newer version, and it took me about 1 hour of hacking and reading documentation. * Likely to be more stable than despotify and support more features with fewer quirks and edge cases than a RE'ed protocol. * Unlikely to result in any disputes from Spotify themselves, since you're just using code that they provide for free, whereas despotify has had run-ins with Spotify in the past. libspotify disadvantages: * This is a closed source library, so from a purely functional perspective, it *won't work at all* on unsupported platforms. Here is a list of the (fairly generous) platforms that are supported: iOS ARM,i386 Android ARM Win32 x86 Mac OS X/Darwin universal linux-libc6 x86 linux-libc6 x86_64 linux-libc6 eabi-armv5t linux-libc6 eabi-armv6t linux-libc6 eabi-armv7 linux-libc6 eabi-armv6hf * Looks like it *might* work on some flavors of BSD through the Linux binary translation layer, but something more unusual like Solaris, Hurd, any unsupported CPU arch, etc. won't work at all without a virtual machine. * This is a closed source library, so from a licensing perspective, any build of mpd that links against this code is non-redistributable. That means we can't have any public binaries (including distro packages) which enable the libspotify support in mpd, or we violate the GPLv2+ license of mpd's source files. Another option is the new(ish) spotify-websocket-api. Apparently, to support some kind of web client, Spotify released a WebSockets API to their protocol. Unfortunately, the only programmatic bindings I can find to this protocol are written in Python (you can find it on github). spotify-websocket-api advantages: * There's an open source implementation (I think it's under 2-clause BSD), so the licensing concerns go away, and mpd is redistributable in binary form with spotify support again. spotify-websocket-api disadvantages: * They're in the same boat as despotify: Spotify can decide to change the protocol whenever they like, or remove it entirely, and we'd be back to having a non-working plugin in mpd. Spotify is not beholden to maintain the interfaces just so that websocket API "unofficial clients" like this can continue to function. * It would be a project in itself to either call these Python bindings from C/C++, or rewrite them in C/C++. README.md in the spotify-websocket-api sources mentions that someone might be working on a Java equivalent, but that doesn't help very much for us in C-land. Judging from these options, I'd lean towards spending my energy on translating the despotify calls in mpd to libspotify. This would at least prevent the code from bitrotting significantly; even a novice C programmer could probably figure out how to refresh libspotify code to use a new version, unless they decide to start their API completely over, but that would result in major upheaval from vendors who are probably paying them lots of money to have Spotify on embedded devices. So I think it is very unlikely that libspotify will change its API significantly, and extremely unlikely that it will be killed entirely, unless Spotify *itself* is killed entirely. So, my questions: * Max, are you OK with the licensing implications of having code in mpd (upstream) that depends on a proprietary library? Obviously you can't stop me from forking and hosting the code myself (as long as I don't publish binaries), but I really, really don't want to do that; I'm more likely to try a different approach than plow forward if you wouldn't accept my code even in principle due to the licensing issue. * Simon, do you agree from a technical perspective that libspotify is probably the best choice at this time? I'm going to start porting/translating the Despotify parts of mpd to libspotify as soon as I send this email, but your replies will determine whether I ever publish my code, and (probably) whether I even finish doing it. Thanks, Sean On Sun, Mar 3, 2013 at 3:29 AM, Simon Kagstrom <simon.kagst...@gmail.com> wrote: > On Sat, 2 Mar 2013 02:10:32 -0500 > Sean McNamara <smc...@gmail.com> wrote: > >> Thanks for your excellent work on the Despotify plugin for mpd! > ' > Thanks! > >> I tried compiling mpd from git, linked against despotify from your >> github, and am getting a crash (see below) when playing >> spt://spotify:track:0VOwC7LKb6KffcjTtrOSAH (or *any* spotify track for >> that matter). > > Yes, this is issue #1 on the github page for my despotify fork: > > https://github.com/SimonKagstrom/despotify/issues/1 > > It was most likely (almost certainly) caused by some change by upstream > spotify. That said, it might still be simple to fix, I don't know. > > I don't work on despotify right now - I have another project which > interests me more, and I'm also on father's leave, so I'm also short on > spare time for working on stuff. Basically it's only possible when my > daughter is sleeping :-) > > > I should also say that the whole reason I forked despotify for starters > was that I couldn't get any reponse from the upstream project for my > changes, so I just started my own branch instead. However, since then, > upstream despotify has awaken again, so there might be fixes there > which we should pick over to the fork. From the svn repo, > > http://despotify.svn.sourceforge.net/viewvc/despotify/ > > it doesn't look like they've fixed this particular issue though. > > // Simon ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
