search

simon-weber / gmusicapi

An unofficial client library for Google Music.
https://unofficial-google-music-api.readthedocs.io
BSD 3-Clause "New" or "Revised" License
2.48k stars 258 forks source link

Single unified client #260

Open sauyon opened 10 years ago

sauyon commented 10 years ago

I think it would be best to provide an abstraction one level higher than the musicmanager/mobileclient/webclient system that's set up right now.

This would mean, say, a simple gmusicapi.client. Of course, in the interest of backwards compatibility, we should keep the three other clients, but deprecate them. Ideally we'd just map the functions in each to a function in the gmusicapi.client package.

sauyon commented 10 years ago

This would probably require ghost.py or the like to do two-factor auth to get an oauth token for the musicmanager client.

EDIT: Only if we want to only have one authentication cycle to access all the APIs. There's definitely a way to get the API token from the web interface, as shown by the music manager app, meaning that a single login to the web interface would mean getting the auth token. Maybe we can access the web interface with an application-specific password? I doubt it, though.

thebigmunch commented 10 years ago

I've provided the same suggestion passingly in the recent past. And I'll make it here again.

Google essentially did the same in their Chrome app, which is just a mish-mash of web, mobile, and musicmanager endpoints and functionality. It may be more complex to develop at first, but it would certainly be far easier for end-users.

Adding to that, a gmusicapi-standard song and playlist separate from Google's own (as mentioned in previous Issues and Pull requests) would also avoid many headaches for end-users.

simon-weber commented 10 years ago

I think this is a nice idea, but would be a lot of work for little payoff; as soon as we have to explain the need for a specific client instead of the generic one, the abstraction has leaked and we've failed. (For what it's worth, gmusicapi used to be this way -- you can see the original reasoning behind separating everything out in #112).

Off the top of my head, here are the biggest differences between the clients:

sauyon commented 10 years ago

Yeah, you're right - they get an auth token from logging in, which was why I was thinking that we might be able to use ghost.py or similar to log in. ClientAuth is going to disappear next year, too, so we'd need to do that anyway at some point.

On Sunday, May 25, 2014, Simon Weber notifications@github.com wrote:

I think this is a nice idea, but would be a lot of work for little payoff; as soon as we have to explain the need for a specific client instead of the generic one, the abstraction has leaked and we've failed. (For what it's worth, gmusicapi used to be this way -- you can see the original reasoning behind separating everything out in #112https://github.com/simon-weber/Unofficial-Google-Music-API/issues/112 ).

Off the top of my head, here are the biggest differences between the clients:

  • auth: no way to unify this unless Google changes the backend
    • webclient, mobileclient: plaintext clientlogin (+ app-specific passwords)
    • musicmanager: oauth (+ proper 2fa)
    • stability:
    • webclient: unstable (google can update client/server code atomically, so there's no need for backwards compatibilty)
    • mobileclient: more stable
    • music manager: very stable
    • streaming support:
    • webclient: easy
    • mobileclient: requires mobile device registration, more flexible (though I don't expose it right now)
    • music manager: requires MAC registration, only full-quality supported
    • upload support: only available with music manager (even when including the new web uploader, I think, since Chrome signin lets them play tricks with auth)
  • schemas/metadata:
    • webclient: doesn't include keys
    • mobileclient: omits some information
    • music manager: omits a lot of information

— Reply to this email directly or view it on GitHubhttps://github.com/simon-weber/Unofficial-Google-Music-API/issues/260#issuecomment-44144992 .

foreverguest commented 10 years ago

Hi Simon, Now that you mentioned, would it be possible to expose a call to obtain the device_id from the mobile client? On the xbmc addon it fails when trying to obtain it via webclient on Android. A lot of people are complaining about that. And it's the only thing missing to get rid of the webclient on the addon.

thebigmunch commented 10 years ago

@foreverguest: It really has nothing to do with this issue and really shouldn't have been posted here. There is already an issue for that. I'm not linking because it doesn't make sense to link it to this issue. It's named "List/deauth upload devices".

thebigmunch commented 10 years ago

As for the topic at hand, hopefully Google gets their auth stuff switched over sooner rather than later (wishful thinking). To clarify, I don't really think a unification should or likely could happen before that time. However, I do believe it would be valuable in the end. I'm not even sure about keeping the separate client interfaces when the best parts of each can be exposed through the unified client instead. Whether the time/effort involved makes it viable remains to be seen.

sauyon commented 10 years ago

Like I was saying, I'd say keep them there for backwards compatibility.

And Google has no reason to switch their auth switched over. They're not using ClientAuth, they're using their /ServiceLogin, which they own and is obviously not deprecated.

simon-weber commented 10 years ago

Oh, did they switch recently? I definitely make clientlogin requests for webclient/mobileclient: https://github.com/simon-weber/Unofficial-Google-Music-API/blob/70328170381b8edc82f6d00cfa94d5c1c3606618/gmusicapi/protocol/shared.py#L342.