Skip to content

Make GetOptionsExt publicly usable #261

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

Closed
gruuya opened this issue Jul 14, 2023 · 4 comments
Closed

Make GetOptionsExt publicly usable #261

gruuya opened this issue Jul 14, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@gruuya
Copy link
Contributor

gruuya commented Jul 14, 2023

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Ideally, to implement the new ObjectStore::get_opts for other object stores based on reqwest clients, we could simply call GetOptionsExt::with_get_options on the RequestBuilder, as is done in the object_store crate itself.

This is not currently possible (I assume inadvertently as the trait itself is public?), since the containing client mod is currently private;

Describe the solution you'd like
Make the trait public/exportable beyond the object_store crate.

Describe alternatives you've considered
Repeat the logic from GetOptionsExt::with_get_options.

Additional context
Over at Seafowl we have a custom HTTP object store implementation for legacy reasons.

@gruuya gruuya added the enhancement New feature or request label Jul 14, 2023
@tustvold
Copy link
Contributor

These extension traits are intentionally private, as they're really just implementation details, that being said GetOptionsExt seems fairly harmless to make public

@Blizzara
Copy link

Hey @tustvold, somewhat related question - would you consider making the whole client mod public? We have our own custom ObjectStore implementation that's backed by an S3 api with some extras, but I think we could reuse most/all of the client. Alternatively I can also just make a copy of it for us, but wanted to check here first :)

@tustvold
Copy link
Contributor

I don't think we could make it public in its current form, the API surface is simply too large and not really designed around API stability.

I think probably we would need something like apache/arrow-rs#6056 to provide a coherent contract, which we could then provide a default implementation of.

@Blizzara
Copy link

I actually ended up copying (and slightly adapting) just the Backoff and Retry implementations. The client itself wouldn't provide us value, but those seemed general enough.

@alamb alamb transferred this issue from apache/arrow-rs Mar 20, 2025
@tustvold tustvold closed this as not planned Won't fix, can't repro, duplicate, stale Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants