Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Following argument made in favour of removing CustomControlTuple type from Buffer server:
Regarding creating custom control tuple as a separate type in bufferserver: I don't think that should be the case since currently this tuple is a passthrough for bufferserver just like any data tuple and there is no action bufferserver takes for this tuple. So why should it be a special type for bufferserver? Window markers are different because bufferserver uses that knowledge. As far as bufferserver is concerned this is just data and the differentiation should be left to the payload.
This might mean adding a byte to the data payload to differentiate between regular data or control tuple which either side, publisher and subscriber understand, but bufferserver doesn't really care about it.
There is a performance argument to be made that an extra byte can be saved by overloading the buffer server message type, but then we should support it more explicitly. For example, you could say that the data tuple type has a message type range from 0xf0-0xff, where the first four bits being all 1's denotes it's a data tuple and the last four bits can be configured by the publisher/subscriber to sub-differentiate the data type. This is just an example, you could go with lesser number of bits. But the point is buffer server will only check the first four bits in this case to determine it is a data tuple and deal with it accordingly, there will be no control tuple definition as far as bufferserver is concerned.