Rigellute
commented
3 years ago Looking forward to these updates @marioortizmanero @ramsayleung. Going to rely on the power of Rust to guide me in fixing the breaking changes.
Open marioortizmanero opened 4 years ago
Rigellute
commented
3 years ago Looking forward to these updates @marioortizmanero @ramsayleung. Going to rely on the power of Rust to guide me in fixing the breaking changes.
marioortizmanero
commented
3 years ago I'm very happy with the progress we're making so far! There's still quite a lot to do, but compared to the state the library was last year, so much has been improved already. Meanwhile you can provide us with some opinions on issues we still are discussing how to solve. I'll try to make them as concise as possible because I know the threads are lengthy now. Answer whatever you can/want, I'll send this to more devs.
https://github.com/ramsayleung/rspotify/issues/4 We want to make it possible to have automatically refreshing tokens (not sure how you handle token refreshing right now) and cached tokens. Would you rather have features in the Cargo.toml to configure what type of token you want to use (token-refreshing and token-cached, for example), or runtime configuration (client.set_cached() and client.set_refreshing() for example)?
The latter would make it possible to use different combinations of tokens in the same program (i.e. a refreshing but not cached one in a part of the program, and a cached but not refreshing in another part), but I'm not sure if that's actually needed. Also unsure if there are more elegant ways of configuring that.
https://github.com/ramsayleung/rspotify/issues/134 How would you rather use optional parameters:
Option: fn endpoint(&self, market: Option<Market>), using it with endpoint(None) or endpoint(Some(Market::FromToken)).fn endpoint<M: Into<Option<Market>>(&self, market: M) so that it can be used as endpoint(Market::FromToken), without Some. The downside is that generics will generate 2^N copies of that function, where N is the number of combinations for the optional parameters used (many times that'll be 1 anyway).https://github.com/ramsayleung/rspotify/pull/166 We want to add an easier interface to iterate methods with paginated results. Should it be an optional feature? In case the feature is activated, should it replace the original methods, or be added as a new endpoint with the _stream suffix? Should it be enabled by default?
These are decisions that are quite complicated to take without insight from others, so we'd appreciate any possible help :)
marioortizmanero
commented
3 years ago Heads up: the new release is finally out! If you need help please let us know at https://github.com/ramsayleung/rspotify/issues/218
Hello!
I'm a maintainer of Rspotify. I picked up this library in July and have made lots of improvements since, with the help of the original maintainer. The library is now much cleaner, more flexible, and more performant. For now, these are the noticeable improvements for the end user:
And we are just at 50% of the changes we intend to make, so it'll be even better. But these kind of improvements require breaking changes. A lot of them, in fact. I wanted to ask the maintainers of this crate (which is one of the most active ones using Rspotify) for help in some discussions relating the future of Rspotify:
Before the new release, we'd like to at least finish these changes, and afterwards we can keep adding new features and prepare for v1.0 in the far future. These include lots of proposals and changes, so don't feel the need to check out each of them. At least a bit of feedback will be useful to us.