search

kubernetes-client / c

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

No way to get data out of a watch callback #194

Closed rcorre closed 3 months ago

rcorre commented 1 year ago

data_callback_func takes a void** for the incoming data, and a long * for the data length. This is fine if you just want to print the object like the examples do, but what if you want to store the data in some structure, or pass it to another component?

It would be useful to have a "user pointer" so we could pass in our own store/component to handle the data, similar to how the writeDataCallback passed to curl has a userp field.

ityuhui commented 1 year ago

A good suggestion! But I have some questions about your use case:

As you know, data_callback_func is a function that requires user to provide/implement, it will only be called in the libcurl callback writeDataCallback https://github.com/kubernetes-client/c/blob/c223563bda143b3ca9e38cbee5782b37cad040a3/kubernetes/src/apiClient.c#L471

How the new userp-for-data_callback_func is passed into writeDataCallback ?

And I think in the customized data_callback_func, you can call a handler function, e.g. https://github.com/kubernetes-client/c/blob/c223563bda143b3ca9e38cbee5782b37cad040a3/examples/watch_list_pod/main.c#LL68C3-L68C3

rcorre commented 1 year ago

How the new userp-for-data_callback_func is passed into writeDataCallback ?

As the data_callback_func is a field on the apiClient, the user pointer could be another field there, so you'd have something like:

apiClient->data_callback_func(apiClient->callbackData, &apiClient->dataReceived, &apiClient->dataReceivedLen);

And I think in the customized data_callback_func, you can call a handler function

There's still no way to get data out of the handler you pass in. In the example on_pod_event_comes just prints the value, but if you wanted to put it in some data structure, or a database, there's no way to do that without using a global.

ityuhui commented 1 year ago

I understand. This is a nice addition to data_callback_func. Would you like to create a PR to implement your idea ? And I have a suggestion for the usage (put the callbackData in the last place):

apiClient->data_callback_func(&apiClient->dataReceived, &apiClient->dataReceivedLen, apiClient->callbackUserData);
ityuhui commented 1 year ago

This code change needs to be committed into the upstream https://github.com/OpenAPITools/openapi-generator/blob/afca85acf577c4117e6eda650d2e228726b57f5c/modules/openapi-generator/src/main/resources/C-libcurl/apiClient.h.mustache#L27 first.

FYI https://github.com/OpenAPITools/openapi-generator/pull/7974

rcorre commented 1 year ago

Thanks! I'm currently waiting on legal approval from my company to sign the CLA.

k8s-triage-robot commented 5 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 4 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot commented 3 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 3 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-client/c/issues/194#issuecomment-2016132244): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.