`AsyncSeek` trait bound on `Reader` may limit options to stream bytes about bevy

[alice-i-cecile]

We need an async / streaming abstraction for assets, but Reader may not be the right design. I'm currently inclined to ship with this for now, and then build out the right one once the rough edges become clearer.

[mockersf]

this is true for any asset reader that could work on a stream, it could make sense for large files on native too

[BeastLe9enD]

I'm just sharing my personal thoughts on it, maybe it will be interesting for others and exciting ideas will arise from it.

I see both sides, on the one hand it can of course limit options to stream bytes for example with an http request that does not support seek, on the other side I think it is really handy in some cases to have the AsyncSeek implementation, like seeking inside a file when only a specific region is needed.

I don't think AsyncSeek will be used often when loading assets in source format, but rather in processed assets. I think that in the future we also want to make it possible for different source assets to be processed with different asset processors, depending on which platform you are on. For example, on platforms that don't support seeking, we could split a large file into several files instead of seeking inside a big one.

Of course, we would still have the problem that all custom readers still have to implement the AsyncSeek trait. For me it feels wrong to have to implement dummy functions for all readers that don't support seeking. I think it would be good if the reader had a function from which you could possibly query optional seek functionality.

Maybe it's the wrong approach to have the seek functionality in the reader, but in my personal opinion it feels pretty intuitive :)