chore: update c-bindings rfc to use callbacks

[richard-ramos]

@Ivansete-status:

Here's the updated RFC using the callback API you proposed for nwaku c-bindings. Notice that some functions in here receive a callback, while they don't in nwaku, (waku_start and waku_stop can fail in go-waku). Should we have the same signature in nwaku even if it is not possible for it to fail on start/stop? (the onErrCallback will never be called there)

Something else that I wanted to discuss with you is how are we going to handle functions that do not receive a string result. for example these:

// Get number of connected peers
extern int waku_peer_cnt(WakuCallBack onOkCb, WakuCallBack onErrCb);

// Determine if there are enough peers to publish a message on a topic. Use NULL
// to verify the number of peers in the default pubsub topic
extern int waku_relay_enough_peers(char* topic, WakuCallBack onOkCb, WakuCallBack onErrCb);

The peer count is supposed to be a number, and the second function is supposed to be a boolean. In this PR I'm returning the string representation of a number and a boolean, but IMO it's ugly. Do you think we should have instead different types of callbacks instead? something like this:

typedef void (*WakuStringCallBack) (const char* msg, size_t len_0);

typedef void (*WakuIntCallBack) (int value);

Then WakuIntCallBack could be used both for numbers and booleans (returning 1 or 0).
What do you think?

[jm-clius]

LGTM in principle, but will let @Ivansete-status review the details here. :)

[Ivansete-status]

Thanks for the thorough update!

Should we have the same signature in nwaku even if it is not possible for it to fail on start/stop? (the onErrCallback will never be called there)

I think yes. I'll adapt the signatures asap

Functions that either return a number or a boolean

I like the approach of having two separate callback types. Maybe another option would be to have a special signatures for each of these functions.

e.g. for a function returning a number:
int get_num(onErrCb)

In this case, the function could return -1 (or any other pre-set value) in case of error, and bring more feedback through the onErrCb. And if all goes well, it just returns the number.

e.g. for a function returning a "boolean":
int get_bool(onErrCb)

In this case, we should define a TRUE value (0) and a FALSE value (1)

---

We can follow the approach that you feel is more convenient :)
Cheers!

[Ivansete-status]

Maybe too many results :P?

Suggested change

	All the API functions require passing callbacks which will be executed depending on the result of the execution result.
	All the API functions require passing callbacks which will be executed depending on the result of the execution.

[Ivansete-status]

Suggested change

	- 2 - The function is missing the `onOkCb` and `onErrCb` callback
	- 2 - The function is missing the `onOkCb` and/or the `onErrCb` callback

[Ivansete-status]

Suggested change

	- 2 - The function is missing the `onOkCb` or `onErrCb` callback
	- 2 - The function is missing the `onOkCb` or the `onErrCb` callback

[jimstir]

Continue discussion: vacp2p/rfc-index#17