{"action":"created","issue":{"url":"https://api.github.com/repos/simon-weber/gmusicapi/issues/430","repository_url":"https://api.github.com/repos/simon-weber/gmusicapi","labels_url":"https://api.github.com/repos/simon-weber/gmusicapi/issues/430/labels{/name}","comments_url":"https://api.github.com/repos/simon-weber/gmusicapi/issues/430/comments","events_url":"https://api.github.com/repos/simon-weber/gmusicapi/issues/430/events","html_url":"https://github.com/simon-weber/gmusicapi/issues/430","id":139417649,"number":430,"title":"Some thoughts/propositions on Subscription/All Access in docs and code","user":{"login":"thebigmunch","id":118418,"avatar_url":"https://avatars.githubusercontent.com/u/118418?v=3","gravatar_id":"","url":"https://api.github.com/users/thebigmunch","html_url":"https://github.com/thebigmunch","followers_url":"https://api.github.com/users/thebigmunch/followers","following_url":"https://api.github.com/users/thebigmunch/following{/other_user}","gists_url":"https://api.github.com/users/thebigmunch/gists{/gist_id}","starred_url":"https://api.github.com/users/thebigmunch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thebigmunch/subscriptions","organizations_url":"https://api.github.com/users/thebigmunch/orgs","repos_url":"https://api.github.com/users/thebigmunch/repos","events_url":"https://api.github.com/users/thebigmunch/events{/privacy}","received_events_url":"https://api.github.com/users/thebigmunch/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2016-03-08T22:50:35Z","updated_at":"2016-03-10T12:19:49Z","closed_at":null,"body":"At first, I started with the idea of updating the docs to the more generic Subscription moniker which Google seems to have taken to using in the Google Music UI and support articles. Along with this, I had implemented a property for Mobileclient to return subscription status for an authenticated Mobileclient instance. The intent was to also use this to possibly add short circuit decorators to methods that required a subscription to provide a more informative message to the user.\r\n\r\n**However**, not being a subscriber myself beyond when I intend to test something subscription-related for gmusicapi, I was surprised to find that many of the All Access methods in gmusicapi no longer require a subscription to use. The main (only?) things that remain subscription-only are streaming non-uploaded, non-purchased songs and adding them to your library. Also, searching can be used by free accounts, but subscription content is not returned in the result.\r\n\r\nSo, the intent of the docs changes I planned remains the same, its scope expanded a bit. I propose to:\r\n\r\n* Move all methods that no longer require a subscription to appropriate headers\r\n* remove any warnings about CallFailure when not subscribed from methods that no longer require a subscription\r\n* change all references to All Access to the more generic subscribed/subscription terminology Google now uses\r\n\r\nAs far as the code goes, here are some possibilities I was thinking about/stumbled upon:\r\n\r\n* Add an ``is_subscribed`` @property to the Mobileclient class using a call to the ``config`` endpoint that is used to populate the Settings window in the mobile app to get the ``isNautilusUser`` setting used to track subscription status\r\n* Add a ``require_subscription`` decorator to methods that require subscription. This seems less useful now that most things don't actually require a subscription, but it may be nice for future-proofing. Also, some methods don't require a subscription unless someone is doing something that requires one (e.g. ``get_stream_url``).\r\n* Add a ``NoSubscription`` or ``NotSubscribed`` exception to raise in cases where it might be possible to give a more specific, useful error message to users.\r\n* The ``search_all_access`` method is now a misnomer. Not only does Google no longer call the service All Access (in visible UI anyway), but it does not actually require a subscription to use the ``query`` endpoint. The query endpoint seems to return only non-subscription stuff like stations and activities if used by a free account indicated by the ``tier`` URL param and, of course, auth. Perhaps this could be renamed to ``search_google_music`` and the param set based on subscription status or even by an argument. Or perhaps use multiple methods, though this doesn't seem preferable.\r\n\r\nLet me know what you think."},"comment":{"url":"https://api.github.com/repos/simon-weber/gmusicapi/issues/comments/194817283","html_url":"https://github.com/simon-weber/gmusicapi/issues/430#issuecomment-194817283","issue_url":"https://api.github.com/repos/simon-weber/gmusicapi/issues/430","id":194817283,"user":{"login":"thebigmunch","id":118418,"avatar_url":"https://avatars.githubusercontent.com/u/118418?v=3","gravatar_id":"","url":"https://api.github.com/users/thebigmunch","html_url":"https://github.com/thebigmunch","followers_url":"https://api.github.com/users/thebigmunch/followers","following_url":"https://api.github.com/users/thebigmunch/following{/other_user}","gists_url":"https://api.github.com/users/thebigmunch/gists{/gist_id}","starred_url":"https://api.github.com/users/thebigmunch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thebigmunch/subscriptions","organizations_url":"https://api.github.com/users/thebigmunch/orgs","repos_url":"https://api.github.com/users/thebigmunch/repos","events_url":"https://api.github.com/users/thebigmunch/events{/privacy}","received_events_url":"https://api.github.com/users/thebigmunch/received_events","type":"User","site_admin":false},"created_at":"2016-03-10T12:19:49Z","updated_at":"2016-03-10T12:19:49Z","body":"I'm not quite sure what use you had in mind for ``validate_subscription_status``, but it has the same meaning as ``is_subscribed`` just longer and uglier. ``is_subscribed`` (not ``is_subscribed()``, btw) will be the property which checks/returns the cached subscription status with a TTL. The question is whether to add a method to force a refresh of the subscription status during that TTL probably with the name ``refresh_subscription`` or similar. But instead, documenting what would be in that method for users to use if necessary is better, since it's unlikely to actually be required and adding a too many methods just makes things worse. Forcing a refresh looks like this:\r\n\r\n```\r\n# Invalidate cache and reset subscription status.\r\ndel self.__dict__['is_subscribed']\r\nself._is_subscribed = False\r\n\r\n# Refresh subscription status.\r\nself.is_subscribed\r\n```\r\n\r\nwhich can easily be turned into a function in user code. That's likely something I'd add to my wrapper, for example. You can even have that function ``return self.is_subscribed`` to return the new subscription status."}}