Inconsistent list split character

[Gavin Greenwalt]

The standard RCP command formatting uses ":" to separate out the different sections.

#[HEADER]:[COMMAND]:[VALUE]:[ChecksumIfApplicable][LF]


But the Caminfo "Command" breaks this formatting by separating the list with ":" is that kosher?

The inconsistency continues to String_Type_Min_Max_Step which uses "|" to separate different items.

Finally Curves use "," to separate types.

Why are there 3 different separators in lists? Couldn't "|" work for all types?

 

[Trent Lillehaugen]

The standard RCP command formatting uses ":" to separate out the different sections.

#[HEADER]:[COMMAND]:[VALUE]:[ChecksumIfApplicable][LF]

Your definition of an RCP packet is not quite correct. It is:
#(@[TARGET_ID])?$[SOURCE_ID]:[COMMAND]:[PARAMETER_ID][VALUE])*\*[CHECKSUM])?[LF]

I'm using regular expression notation, that is:
? = 0 or 1
* = 0 or more

That is, there is a COMMAND, a PARAMETER_ID, and then 0 or more VALUEs.

This is described in more detail in the document "REDLINK COMMAND PROTOCOL: REFERENCE GUIDE" which is part of the RCP SDK download.

But the Caminfo "Command" breaks this formatting by separating the list with ":" is that kosher?

The inconsistency continues to String_Type_Min_Max_Step which uses "|" to separate different items.

Finally Curves use "," to separate types.

Why are there 3 different separators in lists? Couldn't "|" work for all types?

CAMINFO is following the RCP packet it its purest form. Each part of the CAMINFO response is a separate VALUE in the RCP packet. One could argue this is the "correct" way.

The other two examples you cite (lists and curves) are a little bit strange in that they encode their data independently and send it along as one VALUE in the RCP packet. This is done for historical reasons and most likely won't change as to keep backwards compatibility.

Lists are "stringified"and sent as one VALUE field in the RCP packet. Since lists are such an integral part of the RCP protocol we have included code in the SDK to create and parse these "stringified" lists. Again, the details on how to parse the lists strings are found in the document "REDLINK COMMAND PROTOCOL: REFERENCE GUIDE".

Curves should have either been encoded using the separate VALUES in the RCP protocol (like DEVINFO) or each component of the curve as a separate PARAMETER_ID. Unfortunately, it is what it is now.