drwelby commented on issue #6989: URL: https://github.com/apache/arrow-rs/issues/6989#issuecomment-2599798779
The use case stems from @kylebarron's development of using `object_store` to achieve high-throughput, high-concurrency reading of geospatial images using a Rust-based core: https://github.com/developmentseed/aiocogeo-rs The structure of these files is especially suited for http access from cloud storage from S3 so `object_store` fits the base use case very well. However, in my case we have an API that _emulates_ a file in cloud storage. It behaves like an image file stored in S3, but the image is processed on the fly as the file is accessed. At it's core, there is a single "object" - the raw sensor data of the image, but the processing options to create a final image are passed as parameters. So conceptually it's not a great fit for an object store abstraction, but if it's not problematic to allow parameters to slip through, we could use this library, understanding it's "out of spec". Allowing parameters for the state goal of authorization feels like a harmless ask. I have also considered that we instead pack the parameters into a URL structure to make the API behave more RESTfully. Perhaps that's a better direction in general for these times but right now we have parameters. If it's simply not a good fit, that's OK, but I thought I'd ask anyway. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
