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
Which improves a rather simple AssetReader for reading from web-requests.
During this, I was wondering why AssetReaders cannot communicate any context/metadata to AssetLoaders, or even decide which AssetLoader from a list of matching ones (multiple registered for the file extension, for example) to use.
For example, I had to implement a "fake file extension" mechanism which allows adding ..png to the end or a URL. This extension is then stripped before sending the request for cases where an API, for example, doesn't accept file extensions. It would be very nice here for the reader to read the Content-Type header, which could then be used to hint to the AssetLoader for images which format the image is (or even decide outright which AssetLoader to use).
As far as I can tell, though, it wouldn't be possible to return an ad-hoc .meta file only after the asset has been read.
I can also imagine other cases where this could be very useful, as anything which isn't exactly a filesystem will likely have some metadata available which isn't in .meta format.
Is something like web-requests or database queries just too far outside the target use case for bevy_asset?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I was working on:
Which improves a rather simple AssetReader for reading from web-requests.
During this, I was wondering why AssetReaders cannot communicate any context/metadata to AssetLoaders, or even decide which AssetLoader from a list of matching ones (multiple registered for the file extension, for example) to use.
For example, I had to implement a "fake file extension" mechanism which allows adding
..png
to the end or a URL. This extension is then stripped before sending the request for cases where an API, for example, doesn't accept file extensions. It would be very nice here for the reader to read the Content-Type header, which could then be used to hint to the AssetLoader for images which format the image is (or even decide outright which AssetLoader to use).As far as I can tell, though, it wouldn't be possible to return an ad-hoc .meta file only after the asset has been read.
I can also imagine other cases where this could be very useful, as anything which isn't exactly a filesystem will likely have some metadata available which isn't in .meta format.
Is something like web-requests or database queries just too far outside the target use case for bevy_asset?
Beta Was this translation helpful? Give feedback.
All reactions