Hi Xiaokang, Thank you very much for your encouraging and for providing such professional guidance on the roadmap. I truly appreciate your suggestions.
I completely agree that we shoed prioritize the GraphInfo (YAML) parsing system. Following your advice, I will update the current PR (#829) to include the core struct definitions (such as `GraphInfo`, `VertexInfo`, and `EdgeInfo`) first. I will refer closely to the `java-info` implementation to ensure the data structures and logic remain consistent with the GraphAr standard. In the meantime, I will research other Apache Go projects to ensure our project layout aligns with the community's best practices. Thank you again for steering me in the right direction. I will update the PR and look forward to your further review and advice. Best regards, Zeki (Zeyu Liu) On Thursday, January 22nd, 2026 at PM 3:22, Xiaokang Yang <[email protected]> wrote: > > > > +1 (non-binding) > > Thank you very much for bringing the go SDK. > I have some suggestions for your roadmap. We can first create an GraphInfo > (Yaml) parsing system like `java-info`. Then we will discuss the technology > stack of the file system to read and write data in parquet/orc. > > For the file structure, we can refer to other apache go projects. > > Thanks > > Xiaokang Yang > > > On 2026/01/20 15:45:20 "Zeki (Zeyu Liu)" wrote: > > > Hello GAR Community! > > > > I hope this email finds you well. > > > > I am Zeki (Zeyu Liu), a developer interested in building Go support for > > GraphAr. > > > > Following the discussion in #540 [1] and #828 [2], I would like to propose > > a phased approach for the Go SDK. > > > > Initially, I plan to implement the info package natively in Go, drawing > > inspiration from the java-info implementation and other language SDKs' best > > practices to ensure ease of use and maintainability. > > > > For the write path, I suggest leveraging CGO (the mechanism for calling > > C/C++ from Go) to call the core capabilities of the existing C++ library to > > ensure functional alignment. > > > > In the future, we can consider native Go implementations for high-frequency > > community requirements as needed. > > > > My initial roadmap is focused on: > > > > Part 1: Implement the info package and support for the local filesystem. > > > > Part 2: Introduce storage abstraction (e.g., S3) after the core logic is > > stable. > > > > I have submitted a minimal PR #829 [3], which includes a placeholder Go > > module and a basic CI workflow to bootstrap the project. > > > > I would appreciate your feedback on this hybrid approach (Native + CGO) and > > the project structure. > > > > Best regards, > > Zeki (Zeyu Liu) > > > > --- > > > > References: > > [1] https://github.com/apache/incubator-graphar/discussions/540 > > [2] https://github.com/apache/incubator-graphar/issues/828 > > [3] https://github.com/apache/incubator-graphar/pull/829 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
