Few questions around the API

[k2d222]

Hey there, I am considering using this library because I like the idea, and if so, I would contribute to it. I have just a couple questions before I commit to it.

• Do you have plans to evolve or maintain this library? Are you open to contributions and/or suggestions?
• How to parse a file and store it in some in-memory data structure, without serializing? My guess is that you provide a nullptr / None output adapter and write a serialize adapter that fills in the data structure, right?
• Same question the other way around: can you write to a file from an in-memory struct directly?
• are the gvox raw, palette, brickmap, octree... files documented anywhere? (if not thats fine)
• Is the WIP Minecraft parser available anywhere?

Final remark; I like the API design, it looks very simple and allows to write new adapters so easily. But from a usability standpoint, I think it lacks a higher-level API layer. On a high-level, I think the different contexts are a bit redundant, especially in the rust frontend, and maybe so is the distinction between input/parser and output/serializer in common cases. I'll think about it and maybe write something to sort that out.

[GabeRundlett]

• I am absolutely open to both suggestions and contributions
• I'm not sure I understand the question
• If you're coming at it from the rust perspective wanting something like serde, I'm not sure how that'd come into play.
• they are not documented, no
• its code can be found here

Gvox's API is in the process of being completely overhauled in the 2.0 branch at the moment. I had many gripes with the API and wanted to fix those things by adding things like containers, which allow persistent data storage of structures (so you can just keep around and modify an octree for example, and serialize that when you're done) as well as adding iterator support, since the parsing API made no sense to me, now with 2.0 you can just iterate over the data provided by a parser

[k2d222]

Ah thanks! in fact you answered questions 2-3 with 2.0's containers I think. I'll have a look at what's going on on that branch then. Aand looks like, skimming at your 2.0 example file that my concerns about being too low-level ish are also being addressed. Good stuff!