f08f07785b
# Objective The primary motivation behind this PR is to (partially?) address the limitations imposed by the recently added `AsyncSeek` trait bound discussed in issue #12880. While the `AsyncSeek` trait add some flexibility to the reader, it inadvertently restricts the ability to write asset readers that can truly stream bytes, particularly in scenarios like HTTP requests where backward seeking is not supported. It is also challenging in contexts where assets are stored in compressed formats or require other kinds of transformations. The logic behind this change is that currently, with `AsyncSeek`, an asset Reader based on streamed data will either 1) fail silently, 2) return an error, or 3) use a buffer to satisfy the trait constraint. I believe that being able to advance in the file without having to "read" it is a good thing. The only issue here is the ability to seek backward. It is highly likely that in this context, we only need to seek forward in the file because we would have already read an entry table upstream and just want to access one or more resources further in the file. I understand that in some cases, this may not be applicable, but I think it is more beneficial not to constrain `Reader`s that want to stream than to allow "Assets" to read files in a completely arbitrary order. ## Solution Replace the current `AsyncSeek` trait with `AsyncSeekForward` on asset `Reader` ## Changelog - Introduced a new custom trait, `AsyncSeekForward`, for the asset Reader. - Replaced the current `AsyncSeek` trait with `AsyncSeekForward` for all asset `Reader` implementations. ## Migration Guide Replace all instances of `AsyncSeek` with `AsyncSeekForward` in your asset reader implementations. |
||
|---|---|---|
| .. | ||
| macros | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
Bevy Asset
