The CoAP client and server currently contain processing functions with generic names:
process_response(...)
process_datagram(...)
These functions are defined in the corresponding .c files but are not exposed through the public CoAP headers.
Current behavior
The CoAP client response handling and CoAP server datagram handling functions are implemented with generic names inside the source files.
This has two drawbacks:
- the functions are not declared in the corresponding headers, which makes them difficult to reuse or call from other compilation units, for example in tests or platform-specific integration code,
- the function names are not clearly associated with the CoAP client or server module.
Proposed change
Rename the functions to module-specific names:
coapclient_process_response(...)
coapserver_process_datagram(...)
and expose them through the corresponding headers:
src/coap/coapclient.h
src/coap/coapserver.h
The internal call sites should be updated accordingly.
Motivation
Using module-specific names avoids overly generic global symbols and makes the code easier to understand.
Exposing the functions in the headers also makes the processing logic available to other code that needs to pass received CoAP messages into the existing parser/handler logic.
Expected impact
This is a refactoring/API exposure change.
The existing runtime behavior should remain unchanged. The same processing logic is used, but the functions receive clearer names and are declared in the corresponding public headers.
The CoAP client and server currently contain processing functions with generic names:
These functions are defined in the corresponding
.cfiles but are not exposed through the public CoAP headers.Current behavior
The CoAP client response handling and CoAP server datagram handling functions are implemented with generic names inside the source files.
This has two drawbacks:
Proposed change
Rename the functions to module-specific names:
and expose them through the corresponding headers:
The internal call sites should be updated accordingly.
Motivation
Using module-specific names avoids overly generic global symbols and makes the code easier to understand.
Exposing the functions in the headers also makes the processing logic available to other code that needs to pass received CoAP messages into the existing parser/handler logic.
Expected impact
This is a refactoring/API exposure change.
The existing runtime behavior should remain unchanged. The same processing logic is used, but the functions receive clearer names and are declared in the corresponding public headers.