original thought of chaining parameters is to have a possibility to send more than one parameter in one packet
2 aspects:
optimized byte-size by removing protocol overhead
synchronized parameter add/update/remove
ad 1)
2 ways to solve this:
a) write parameter-count as option before the chained parameters
b) (preferred) introduce another terminator-id to signify continuation
but:
add/update/remove parameter are not time-critical, no need to chain and safe some bytes
the optimized updateValue command is so minimal, that we do not gain anything by chaining (by introducing a continuator-byte)
-> no chaining needed
ad 2)
chaining parameter would allow a synchronized update of parameters (which the optimized updateValue doe not allow right now), something like a flush.
question: is this wanted / needed?
in case of chaining parameters: user cannot directly affect chaining of parameters. server/client can be clever about and and decide to chain multiple parameters in one package.
joreg
commented
6 years ago
original thought of chaining parameters is to have a possibility to send more than one parameter in one packet
2 aspects:
ad 1)
but:
-> no chaining needed
ad 2)