As stated above, an unsorted key word based transaction protocol seems to have the best potential for future improvements and additions to the communication interface without the loss of compatibility between non-exact matching displays and analysis components. In our case, such a request looks like the following (translated from binary):
REQUEST::RequestTimeline,
KEY::Threads, INT(4)::1, 2, 4, 8,
KEY::TimeIntervalStart, FLOAT(1)::StartTime,
KEY::TimeIntervalStop, FLOAT(1)::StopTime,
KEY::HorizontalResolution, INT(1)::800.
The ordering of the parameters can be arbitrary. Furthermore, additional unknown or obsolete parameters are allowed, but ignored. Serialization, type translation, and packaging of such requests are generic tasks that work just fine for any future extensions. The above example is written in ASCII text to give an idea of what a generic protocol looks like. The real format of course is a tokenized binary representation, although for debugging purposes, a human readable format is useful as well. This only affects the packaging layer of our model. Again, this is one of the benefits of a multi-layered client/server interface.