Xuanwo
cc @PsiACE and @LYZJU2019, any updates on this?
Here are my brief ideas on implementing this service. ## Tasks - [ ] setup servies (add deps, figure out CI, add `Access` place holder) - [ ] implement core...
I believe we should focus on getting our services layout ready first. https://github.com/apache/opendal/pull/5269 is almost ready but still needs some work. Maybe we can leave all functions unimplemented for now....
Great, thanks a lot!
We previously had `services-all`, but deciding which services to include under `all` proved challenging: - `hdfs` requires a JVM and libhdfs. - `foundationdb` requires `libfoundation`. - `sftp` is only available...
I'm uncertain whether it's common practice to have a `libopendal_cpp_service_s3.so` that solely provides S3 configuration and builder for `libopendal_cpp.so` to utilize.
> e.g. `services-all-pure-rust`, `services-requires-jvm`, `services-require-c-compiling`, `services-requires-unix`... I personally find this matrix difficult to maintain and stabilize.
Hi, I'm going to close this issue as there are no actionable tasks remaining.
> A feasible solution currently is to replace `opendal = { path = "../../core" }` with a specific version in the `Cargo.toml` file located in `binding/ocaml`. I'm ok with pinning...
I feel like we can release ocaml binding separately. For example: 1. Release the ocaml binding source first. 2. Submit PR to ocaml registry after ASF release approved.