C Port of RADE V2

[drowe67]

Claude doing his magic, backed by ctests from drowe67/radae#70.

See https://github.com/drowe67/radae_nopy/tree/dr-radev2 for V2 C Port test results.

WIP - do not merge.

The on-air waveform is not frozen and is likely to change at anytime

[drowe67]

@peterbmarks @tmiw - thinking about naming conventions for V1 & V2 code in this repo.

So Claude has come up with rade_v2_tx and radae_v2_rx for the cmd line V2 Tx and Rx. Should the current rade_tx and rade_rx be renamed rade_v1_tx and rade_v1_rx for consistency? There are probably other example in the code where we could apply similar conventions.

In drowe67/radae#70 I've renamed the ctests radae_nopy_v1_xxx and radae_nopy_v2_xxx.

[peterbmarks]

I think rade_vX_tx etc is good. (Leaves the door open to v3)
Should we keep old public methods so as not to break any uses in existing code, we could mark the old ones with deprecated to generate a warning.
I think we should also get rid of any mention of "nopy" as it's clearly already in the filename extension.

[drowe67]

Should we keep old public methods so as not to break any uses in existing code, we could mark the old ones with deprecated to generate a warning.

You mean the API? Lets take a look at that next.

[tmiw]

Using a version in the function names would be good.

Also, what about adding a function to the existing API to indicate which version to use (and then eventually default to using the RADEV2 implementations or something)? For example:

struct rade* rade = rade_open(...); // uses RADEV1, will eventually be the same as rade_open_with_version(RADE_VERSION_2, ...)
struct rade* rade2 = rade_open_with_version(RADE_VERSION_2, ...);

Then internally (for example):

struct rade* rade_open_with_version(int version, ...) {
    struct rade* result = malloc(sizeof(struct rade));

    if (version == RADE_VERSION_1) result->impl = rade_v1_get_impl();
    else if (version == RADE_VERSION_2) result->impl = rade_v2_get_impl();
    ...

    // additional initialization here
    return result;
}

int rade_tx(struct rade* rade, ...) {
    return rade->impl.tx(rade, ...);
}

Anyway, just thinking from the perspective of RADEV2 being a thing for potentially quite a while before there's a V3. If we want something quick we can just have e.g. rade_v2_tx and rade_v2_open and expect users to use those if they want V2.

EDIT: whoops, I think @drowe67 and I commented at the same time. We can look at rade_api after for sure.

[drowe67]

EDIT: whoops, I think @drowe67 and I commented at the same time. We can look at rade_api after for sure.

That's fine - what you are brainstorming is the topic I was suggesting we discuss.

TBH I'm not as worried about breaking the API at this stage - it's pretty early days and the fix (like adding a version argument to rade_open) will be pretty straight fwd. End users will only be upgrading to get V2, so will already be making changes to the way they open the library.

But I'm not mandating anything atm - lets ponder it and form a consensus.

[peterbmarks]

I'm not sure that sharing rade_open returning a pointer to the rade structure can work as that struct might change with future versions. It contains rade_tx_state and rade_rx_state and they could also be different.

Maybe we should just go with rade and rade2?

Also, it's good to build a few clients apps that use the API and collect ideas of what the API should expose.

[tmiw]

I'm not sure that sharing rade_open returning a pointer to the rade structure can work as that struct might change with future versions. It contains rade_tx_state and rade_rx_state and they could also be different.

Maybe we should just go with rade and rade2?

Also, it's good to build a few clients apps that use the API and collect ideas of what the API should expose.

There could also be a private state inside the struct that could be initialized/used in a version dependent manner. But as mentioned, if we're already going to be breaking compatibility anyway...