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.
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.
Feature Description
OperatorRegistryalready stores every registered scheme in its internalfactories: 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 setOperator::from_urican handle.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_uriis the one construction path where an unsupported scheme fails at runtime rather than as a compile error or a visibleCargo.tomlfeature flag. On a scheme with no registered factory,OperatorRegistry::loadreturnsErrorKind::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-inservices-*features and is otherwise unobservable at runtime.So a common mistake — a wrong dialect (
s3a://,gs://vsgcs://) or a missingservices-*feature — yields a bare "scheme is not registered", with no hint that the fix is "enable the feature" or "you meants3".schemes()closes this: OpenDAL can enrich thefrom_urierror itself (e.g.(available: fs, memory, s3)), and callers wrappingfrom_urican validate a scheme before building instead of probing by trial-and-error.Additional Context
factoriesis already aMutex<HashMap<String, OperatorFactory>>, soschemes()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 thefrom_urierror message in the same PR. Happy to send it.