Add support for like.fm

[GoogleCodeExporter]

Description of the new feature:

http://like.fm is a very cool site, supporting it would be 
great.

I've been told that the API is the same as lasft.fm

Cheers,
Carl

Original issue reported on code.google.com by name.is....@gmail.com on 7 May 2011 at 8:43

[GoogleCodeExporter]

After some digging (and some testing) it appears that 
like.fm's API is the same as LastFM's with one exception.

The password is transmitted over HTTPS in clear.

So it means that the logic of the simple last.fm 
application would have to be adapted by adding a field in 
the NetApp class : supportHttps (which would be true
only for likeFM).

If supportsHttps is true, the password would be used instead 
of md5 hash and *not* be cleared once
the handshake is done. (the password could be stored in an 
encrypted form, though).

Would this be acceptable ?

If so, I could submit a patch for review.

Original comment by name.is....@gmail.com on 7 May 2011 at 12:55

[GoogleCodeExporter]

I read here: http://like.fm/developers that the API is supposed to work exactly 
like the Last.fm one. That would be best, if it were so.

I really don't want to store plaintext passwords. How do you propose to safely 
encrypt it? 

I had some ideas a while back (that I didn't implement) for each 
"scrobble-target" (Last.fm, Libre.fm, Like.fm, plain text file, etc.) to be 
able to specify their own components (handshaker, scrobbler, etc.). This would 
make it much more customizeable, and would lead to cleaner implementations of 
non-last.fm-identical apis.

Original comment by tgwizard on 8 May 2011 at 12:45

• Changed state: Accepted

[GoogleCodeExporter]

> I read here: http://like.fm/developers that the API is 
> supposed to work exactly like the Last.fm one. That would be best, if it were 
so.

It sure would :) But we could give the like.fm team some slack : the service 
is quite new...

> I really don't want to store plaintext passwords. 
I understand 100%
Well as a matter of act, there may be another way to do things without
the need to store the password...

I'll tell you more about it at the end of my tests !

> This would make it much more customizeable, and would lead to cleaner 
> implementations of non-last.fm-identical apis.

You mean classes like LikeFmScrobbler, LastFmScrobbler inheriting 
from an abstract ScrobblerBase class ? And a separate 
enumeration/class with an instance of each scrobbler type ?

I think this the way to go. And provided that your code is very clean, 
the transition will be pretty painless...

Original comment by name.is....@gmail.com on 8 May 2011 at 1:39

[GoogleCodeExporter]

I modified the API so that it now it takes an MD5 of a passcode. So the 
existing Last.fm code should work as-is. However the user would have to input a 
token on this page: http://like.fm/settings instead of their password and I 
guess all you would need to do is put some language there when you select 
Like.fm telling the user to retrieve their passcode from that page.

Original comment by chris.ch...@gmail.com on 9 May 2011 at 1:23

[GoogleCodeExporter]

Like.fm accepts extra parameters when notifying the "now playing"/played state.
The source for of the application is one them (track.getMusicApi().getName()

Of course such parameter are not accepted by the other services. Which weigh in 
favor of the refactoring suggested : one class for each supported scrobbling 
service :)

Original comment by name.is....@gmail.com on 27 May 2011 at 2:39

[GoogleCodeExporter]

Hi, I've moved the project to github, https://github.com/tgwizard/sls. Could 
you please add the issue there instead?

I'm sorry I haven't had time to do anything about this. And it has been over a 
year. If you want, you can always do the coding yourself, and make a pull 
request (on github).

Best regards,
Adam

Original comment by tgwizard on 28 Jul 2012 at 10:34