-
Notifications
You must be signed in to change notification settings - Fork 1
Upgrade to object_store 0.12.0 RC, tinker with upstreamable version #45
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
Comments
Alright, findings so far. First, showstoppers:
Strongly recommended for upstream:
1st party HttpConnector for wasm32 targets, upstream:
Remaining sticking points:
Ongoing role of this crateThe JS bindings (WasmObjectStore, WasmObjectMeta, WasmGetOptions, and the object store adapter methods) don't make a lot of sense to upstream (certainly not in the object_store crate, and there isn't really a suitable workspace slot for it), unless people are eager for it. The current method adapters (specifically the conversion of rs streams to equivalent JS ReadableStreams) are fairly uncontroversial, but don't amount to much on their own. The direction I'd like to take this crate in is quite specific to wasm32 environments, specifically the panoply of non-remote object store or filesystems:
Most of that is irrelevant (and frequently has no equivalent) on other targets. |
I'd encourage you to write this comment here too apache/arrow-rs#6818 |
Depending on whether a full form of this is upstreamable, this could be an opportunity to sunset this repository. Let's see.
The text was updated successfully, but these errors were encountered: