search

kubernetes-client / c

Official C client library for Kubernetes
Apache License 2.0
141 stars 45 forks source link

Feature Request: Decoupling parsing from network message passing #224

Closed homer6 closed 4 months ago

homer6 commented 4 months ago

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

https://github.com/kubernetes-client/c/issues/221#issuecomment-1969919642

ityuhui commented 4 months ago

We have a generic client and you can parse the JSON results yourself. See the example.

Maybe you can wrap this for your client.

homer6 commented 4 months ago

Awesome. I'll give that a shot. Thanks!

ityuhui commented 4 months ago

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.

brendandburns commented 4 months ago

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.

homer6 commented 4 months ago

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!