Feature Request: Decoupling parsing from network message passing
homer6 opened this issue · comments
Recently, I was able to work around the parsing capabilities of each method by modifying the implementation of CoreV1API_listNamespacedPod
to just return the apiClient->dataReceived
pointer (and not free it) instead of the parsed data structure. I then casted the pointer as a char *
and freed it after use. This was useful as then I could void some glitches in the parsing code and just parse the JSON directly.
Could we add a feature to all functions that effectively does this for all functions? eg. skipParsing=true
We have a generic client and you can parse the JSON results yourself. See the example.
Maybe you can wrap this for your client.
Awesome. I'll give that a shot. Thanks!
For application development, the generic client is convenient.
But if I'm not mistaken, you're developing a library, tracing the Kubernetes API changes after every release and parsing the JSON yourself will cost lots of efforts.
I would strongly suggest that you use the C++ generator from here:
https://github.com/OpenAPITools/openapi-generator
You can modify the gen repo here:
https://github.com/kubernetes-client/gen
To use the C++ generator (and then send us a PR and we can include that)
You may be able to re-use a bunch of the config parsing and auth code in this library to speed up the work, but as @ityuhui mentions, keeping up with the Kubernetes API surface area without code generation is a lot of work.
Thanks @ityuhui and @brendandburns
I was able to successfully apply the generic API and that cleared up all of the issues that I was having.
I'll keep the generator concept in mind; however, the design that I'm going for is a more high-level API that just proxies resources and queries to the k8s API. I don't want to create and whole in-memory model and classes because they don't add much, if any value, they pollute the instruction cache, and they're a maintenance nightmare to keep up to date with (even with generators).
I think we can close this feature request because the generic API was very successful. Thanks again to you both!