chitralverma opened a new issue, #7904:
URL: https://github.com/apache/opendal/issues/7904
## Feature Description
`OperatorRegistry` already stores every registered scheme in its internal
`factories: Mutex<HashMap<String, OperatorFactory>>`, but there is no public
way
to read those keys back. I'd like a public accessor that returns the set of
registered schemes — which, for the global registry, is exactly the set
`Operator::from_uri` can handle.
```rust
impl OperatorRegistry {
/// Return the schemes currently registered.
pub fn schemes(&self) -> HashSet<String> {
self.factories
.lock()
.expect("operator registry mutex poisoned")
.keys()
.cloned()
.collect()
}
}
```
A thin read over the existing map — no new state.
`OperatorRegistry::get().schemes()`
would expose the set for the global registry.
## Problem and Solution
`Operator::from_uri` is the one construction path where an unsupported
scheme fails
at *runtime* rather than as a compile error or a visible `Cargo.toml`
feature flag.
On a scheme with no registered factory, `OperatorRegistry::load` returns
`ErrorKind::Unsupported` `"scheme is not registered"` with the offending
scheme — but
**cannot list which schemes *are* available**, since the registered set is
unreadable
(`registry.rs:74`). The set is fully determined by the compiled-in
`services-*`
features and is otherwise unobservable at runtime.
So a common mistake — a wrong dialect (`s3a://`, `gs://` vs `gcs://`) or a
missing
`services-*` feature — yields a bare "scheme is not registered", with no
hint that
the fix is "enable the feature" or "you meant `s3`".
`schemes()` closes this: OpenDAL can enrich the `from_uri` error itself (e.g.
`(available: fs, memory, s3)`), and callers wrapping `from_uri` can validate
a scheme
before building instead of probing by trial-and-error.
## Additional Context
`factories` is already a `Mutex<HashMap<String, OperatorFactory>>`, so
`schemes()`
just collects its keys under the existing lock — no new state, no API
surface beyond
the one method. Return type (`HashSet<String>` vs iterator) is open to
maintainer
preference. This could pair naturally with enriching the `from_uri` error
message in
the same PR. Happy to send it.
- [x] Yes, I am willing to contribute to the development of this feature.
--
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]
