Xuanwo commented on PR #966: URL: https://github.com/apache/iceberg-rust/pull/966#issuecomment-2673388726
For @wgtmac > * Is it a battery-included solution or is flexible enough to let downstreams plugin their own implementations of I/O (cloud object store, hdfs, async I/O, etc.), file formats (parquet/avro/orc)? This has been discussed a lot in the iceberg-cpp project and should be the 1st priority. It will be battery-included solution but can split into different modules so that users can use their own IO. > * Is there any limitation to support different architectures (e.g. ARM) or platforms (e.g. Windows)? No limitation on mainstream platforms. (x86_64, ARM) × (Linux, macOS, Windows) are known to be supported. The complete list of supported platforms can be found at https://doc.rust-lang.org/nightly/rustc/platform-support.html. > * Is it possible to automatically generate C++ headers to be more friendly to C++? [cbindgen](https://github.com/mozilla/cbindgen) also supports generating C++ headers, but I haven't tried it yet. I'll take a look if needed. It's also possible to use [`cxx`](https://github.com/dtolnay/cxx) to create a pure C++ binding, but it depends on the direction we want to take for iceberg-cpp. > * Is there any performance penalty compared to a pure C/C++ implementation? This FFI bridge operates at zero or negligible overhead, i.e. no copying, no serialization, no runtime checks needed. --- For @lidavidm > I'm also curious if there's any potential for linking issues if say, we use this (with OpenDAL enabled) and also OpenDAL's C++ bindings separately. I believe they will work seamlessly since neither iceberg-rust nor opendal has runtime or global variables to share. > I'm also assuming (given Rust has no stable ABI) that this builds one shared object with all enabled features; given that maybe another thing to think about (down the line!) is integration with CMake etc. so consumers can choose which features to build and link more easily? Yes, it is definitely possible. We have explored this in OpenDAL, where we can build it using only selected services or disable async support. Users can control these options through different CMake profiles. -- 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: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
