Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce scope of module #35

Closed
yoshuawuyts opened this issue Oct 9, 2019 · 0 comments
Closed

Reduce scope of module #35

yoshuawuyts opened this issue Oct 9, 2019 · 0 comments

Comments

@yoshuawuyts
Copy link
Contributor

Motivation

As part of the winding down of the "Async Ecosystem WG" we've taken over maintainership of this crate in async-rs.

Our resources to review things have been quite limited, and because there is a lot of overlap between the work of the two crates it can be hard to keep up. For example #24, #26, and #28 have been open for months now but we haven't been able to find the time to accurate review all changes.

Proposal

Therefor I'd like to propose we significantly reduce the scope of this module by removing all Ext impls, intervals and other high-level components. This would be in line with async-rs/async-std#275.

In addition to that I suggest we build out a new, high-level module, on top of futures-timer for experimental additions to async-std. An initial design doc can be found here.

Conclusion

Hopefully this will bring us into a position where it's easier for everyone to maintain code, the layers are more clearly separated, and we're able to respond faster to change. In turn we can then start looking towards creating and testing new backends that share a similar API, for example based on hashed wheel timers (async-rs/async-std#170) or browser-based timers (https://github.com/tomaka/wasm-timer). Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant