dpol1 commented on issue #3110: URL: https://github.com/apache/hugegraph/issues/3110#issuecomment-5078038478
I'd be interested in taking the interop/build/test foundation work before proposing a server component. Fair warning, I'm not a Rust person. My work here has been compatibility and failure handling (#3062). Where I'd be useful is the build, test and licensing plumbing someone has to do anyway. Poked around a bit first. Few things that might save time for whoever picks this up: - root pom is JDK 11, so there is no stable FFM API at the project baseline. JNI is the obvious in-process baseline; an out-of-process boundary is the other architectural option. - hugegraph-commons is still Java 8, so a native seam there has a tighter floor than one under hugegraph-server. - HugeGraph now supports x86_64, aarch64 and riscv64. Any eventually distributed native component will need an explicit support/fallback policy; #3102's smoke-test infrastructure looks reusable. - Apache OpenDAL already ships a Rust JNI binding: exec-maven-plugin for the cargo build, classifier jars via os-maven-plugin, crate licenses in a DEPENDENCIES.rust.tsv. Not saying we copy it, but the release-side questions have an answer somewhere. One catch: their non-classifier jar simply has no native lib in it, it's not a Java fallback, the loader throws if nothing loads. Whether we want graceful degradation instead is a real decision. Worth noting the root pom already pins `os.detected.classifier` to `osx-x86_64` on ARM Macs, so anything keyed on that property would need handling there. On picking the first PoC, I'd rather not name a component. A small matrix (test oracle? how many call sites? work per call? does it touch a persisted format?) plus a rule for when a JNI hop pays for itself makes it easy to move on when the first pick doesn't hold up. Small first thing, no Rust until there's agreement: a compat inventory of the codec classes, a golden fixture corpus in plain Java that can merge on its own, and an interop draft (JNI seam, failure semantics, packaging) as a child issue. Questions: does this fit the toolchain -> server ordering, or should it wait behind apache/hugegraph-toolchain#748? Park packaging for now, or is the classifier jar shape what you'd want? And is anyone up for mentoring / picking the first component? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
