reduce repeated examples.

[ramsayleung]

All of these example files come from a same template, which are are quite repetitive and don't offer much help for real projects, the only difference between them is that they calls different function with different day, everything else is same.

• remove repetitive examples.
• add some real examples.
• update document.

[marioortizmanero]

I would reuse the examples and turn them into tests, rather than completely remove them. That way we have full coverage for every endpoint. Oh I've seen these tests already exist.

I wanted to suggest to use a refresh token with all scopes already given for the test_with_oauth. We could use it to avoid user interaction, and that way they can be ran with Travis as well, since they aren't supposed to expire. This requires a premium account for the library, so I made a request for an account to Spotify - https://community.spotify.com/t5/Spotify-for-Developers/Dummy-premium-accounts-for-library-developers/td-p/5018210

By the way, sorry about the force pushes, the 4 following commits don't change anything. The fifth adds a new example called with_refresh_token. Let me know what you think about it.

[ramsayleung]

I wanted to suggest to use a refresh token with all scopes already given for the test_with_oauth. We could use it to avoid user interaction, and that way they can be ran with Travis as well, since they aren't supposed to expire.

Yep, it's a great idea to run tests, and the key point how to get a non-expire refresh-token. Hopefully you could get the premium account.

By the way, sorry about the force pushes, the 4 following commits don't change anything. The fifth adds a new example called with_refresh_token. Let me know what you think about it.

The example called with_refresh_token is helpful to demonstrate how to refresh token, but I think force push it's not a good idea, perhaps it will overwrite something important.

[marioortizmanero]

No, the force push was because I created a commit by mistake and then dropped it later. You can do a rebase and merge and I think it'll be ok, without overwriting anything.

[marioortizmanero]

Ok so I think I've managed to get the GitHub README to be much more straight to the point. The documentation for Rspotify itself is now inside the docs.rs site instead of split between different places, and the GitHub README is now limited to basic information. Do let me know what you think about the changes I've made.

I suggest using cargo doc --features=blocking to have access to these docs as well. Not sure if this can be included in Cargo.toml.

[ramsayleung]

The documentation for Rspotify itself is now inside the docs.rs site instead of split between different places,

Sorry for not getting your point, what do you mean about splitting between different places?

and the GitHub README is now limited to basic information.

I think it's the de-facto way to maintain documentation in docs.rs in Rust community, and leading the people to the documentation in docs.rs by putting a link in the Github README, is it meaning of limitation in your opinion? I think it's a acceptable way to maintain documentation.IMHO, the key point of documentation is its quality, not the place keeps it.

[marioortizmanero]

Sorry for not getting your point, what do you mean about splitting between different places?

What I mean is that, in my opinion, the README currently has too much documentation. It shows how to configure Rspotify (its features and such), how authorization works, and includes a couple examples. I think it's easier to have everything documentation-related in docs.rs and just have the README point to the site. That way we don't have repeated documentation either, because I realized that most of the README was copy-pasted into the docs.rs page anyway.

For example the "Getting Started" section shouldn't be in the README IMO because that's related to the documentation. And by having the examples in the documentation, they are also ran with cargo test to make sure they're valid.

I'm just trying to follow what tekore, rand, bitflags and other libraries do, since I consider the documentation easier to follow that way. Their READMEs only contain information regarding the development of the library, since GitHub is only supposed to serve as a platform for development and hosting. Thus, I just moved a few sections to docs.rs. If you consider any of them could fit better in the README, let me know.

[ramsayleung]

If you consider any of them could fit better in the README, let me know.

I get your point now, I think is the good way to follow the best practice, as what other libraries do, moving some section from Github to docs.rs.

[marioortizmanero]

Great! All that's left is adding more examples, but I'm not sure how many you want before this is merged. Do you plan on adding any yourself?

[ramsayleung]

Do you plan on adding any yourself?

Yep, I am planning to add some real-world examples.

PS: I am adding a new Web App example based on Rocket

[marioortizmanero]

Neat example with the Rocket web app, I like it. Can this be merged for now, then? We can add more examples in the future and this is blocking other issues/PRs.

[ramsayleung]

Yep, merged :)