xmidt-org / wrp-c Goto Github PK

session_id should be added as a top-level property of all WRP messages that represent events.
The field represents a unique identifier that represents a single connection session between a device and talaria.

When we successfully create a msgpack message the code performs a msgpack_zone_destroy() call, but when there are errors, the code does not. This seems like a potential memory leak. Is that the case?

We should support the partner_id field de/serialization.

https://github.com/Comcast/wrp-c/wiki/Web-Routing-Protocol/_compare/68a10f63e239db527275f59d1a317a45a66b39b4...bb9fbc5ab73300e25cc12f5a3219b428851a1ea5

From the first time wrp-c supported partner_ids, it has been limited to only accept one partner_id.

https://github.com/xmidt-org/wrp-c/blame/c2bc9be9dad6b0e4f7f9138f3d1074702ace7976/src/wrp-c.c#L1442

This is an issue because it should support multiple values in the array.

The status field is missing from the RequestResponse message.

Not sure what the problem is yet, but the current failed MacOS build is due to this output:
https://github.com/xmidt-org/wrp-c/runs/5235892203?check_suite_focus=true#step:7:16

This line could access uninitialized memory as it does not respect the specified limit.

In order to get everything in the right order on the linker command
line, external libraries need to be defined via LINK_LIBRARIES (and
not via LDFLAGS).

https://github.com/Comcast/wrp-c/blob/master/src/wrp-c.h#L37

We will need to add a duplicate enumeration that is spelled correctly and incorrectly so we don't break other projects.

Within the CRUD message definition & Simple Request-Response Definition clarify spans correct data format. Currently it is in the air to what the final form should be: a strings to strings, or a map of strings to strings.

The WRP lists the current spans format as:
"An array of arrays of timing values as a list in the format: "name", "start time", "duration""

Also have to change references to the branch in .travis.yml, README, and CONTRIBUTING. Double check any other markdown files as well - sometimes links have the branch name in them.

It looks like the accept field got overlooked in the RequestResponse message, and in the documentation for CRUD as well. I have updated the documentation, but it needs to be supported in both.

The use of va_copy() requires a va_end() that is not present.

As defined now, the CRUD interface only allows JSON, but it should allow a binary payload and include a content-type. This enables much more flexible code in the future.

ssize_t can only hold the same values as size_t and -1. Any other negative value is technically undefined.