add support of ThreadsResponse id name type fields#303
add support of ThreadsResponse id name type fields#303RokuSerhii wants to merge 4 commits intorokucommunity:masterfrom
Conversation
| // build the list of threads | ||
| for (let i = 0; i < threadsCount; i++) { | ||
| const thread = {} as ThreadInfo; | ||
| const flags = smartBuffer.readUInt8(); |
There was a problem hiding this comment.
Many other places in the debug protocol, the specific response includes a flag saying a new property was available. I would expect the firmware to set the flag on this response, and then our code in roku-debug would read it from that flag, instead of inspecting the debug protocol version.
There was a problem hiding this comment.
We could change the logic to read all packetLength smartBuffer.readOffset < response.data.packetLength instead of tracking the protocol version, as adding an additional property that indicates about new properties anyway will corrupt the thread response structure and also the debugger client needs to know how to read this new data
There was a problem hiding this comment.
But that's what the flags field is specifically for. Look at VariablesResponse as an example. The bitwise flags field is there to intentionally NOT corrupt the repsonses, and indicates that new data is available.
And ThreadsResponse already supports that concept. We're currently reading IS_PRIMARY, but all the other bit slots are fair game. (so 0x02 for example could be includes_additional_thread_indo).
2 participants
No description provided.