As part of the standardization attempts in KISSCPP a decision was made to use JSON as a communications protocol. Yes, there are more optimal protocols to use in terms of speed, and yes, there are better protocols in terms of human readability.

JSON however, is the best match for both speed and human readability.

Is human readibility important?

If your are a Computer Science student, your answer is probably: No.

If you've spent any amount of time trying to figure out the spaghetti code, created by someone who left the company 3 years ago, your answer is probably: Yes.

KISSCPP is meant to be used in the real world, by organizations that can suffer a 15 millisecond delay in IPC speed, but can not suffer the three days debugging time on an unreadable protocol.

All software needs debugging at some point, and as such, needs to be read by humans. i.e. Human readable comms protocols are important, and KISSCPP will provide.

This however, does not exclude the possibility of non-human readable protocols being used in the future, if such becomes available in the boost property tree tools.

Reserved identifiers.

Within the context of JSON as a protocol, we need to standardise on a few identifiers, in order to make sure we can handle communication basics. Note:

The kcm prefix, is shorthand for (K)iss(C)pp (M)essage. To prevent conflict between KISSCPP specific communications and your own application data, do not prefix any of your custom configuration variables with kcm.

Identifier	Required in	purpose/meaning	Description	typical values
kcm-cmd	Request	Handler Id/Command	A string, uniquely identifying the server handler to invoke.	An arbitrary string.
kcm-sts	Response	Status	Used in the response to indicate request status	Enumerated.
kcm-erm	Response: where kcm-sts != 0	Error - message	An error message	An arbitrary string.
kcm-hst	instance of client class	host	used by client class to indicate server host	An arbitrary string.
kcm-prt	instance of client class	port	used by client class to indicate server port	An arbitrary string.
kcm-client	Request	A root node	A root node for the id and instance of the requesting app	Nothing
kcm-client.id	Requests	App identifier	The id of the application. Typically set to the name of the compiled binary executable.	An arbitrary string.
kcm-client.instance	Request	App instance identifier	The instance id of the application. Used to differentiate between multiple processes of the same app.	An arbitrary string.

Basic terminology

The digram below provides a view on terminology problems I need to get out of the way here. The phrase "Making a request." with respect to inter process communication, could mean steps 1 through 6, or simply step 1 or even steps 1 through 3.

So, in order to make my life easier and improve understanding of documentation, I'm going to use a simple convention, that uses this diagram, to get rid of all the ambiguity with regard to talking about the various stages of inter process communication at application level.

I'll be using the word IPCOM, followed by parenthesis, and the steps I'm referring to, contained within the parenthesis.

i.e.

IPCOM(1-2) would be referring to steps 1 and 2 on the digram.
IPCOM(1-5) would refer to steps 1 through 5, while
IPCOM(4) would refer to only step 4.

With that in mind, I'd now be able to say: IPCOM(1-6) and you'll instantly know I'm referring to the entire communication cycle.