You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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 toasync-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!
The text was updated successfully, but these errors were encountered: