Select variant based on value in the transport frame

[TimonTerBraak]

I am modeling a protocol that contains a request-reply pattern, where the payload of the reply can only be identified by an identifier that the clients puts into the transport frame of the request. In other words, I can decode the reply based on information that is ony known by the client and echoed by the the server.

I first did some manual decoding of the payload, but then I end up doing the same stuff where comms is the champ ;-) So, I modeled that as well in commsdsl, in the form:

<variant>
  <bundle/>
  <bundle/>
  <bundle/>
</variant>

I studied the commsdsl manual and tutorial4 of the cc_tutorials. However, me payload has no key to identify what variant to select. I tried the following two approaches, but failed to get it to work:

1. Insert a 'pseudo' key into the bundles with a 'validValue' identical to the key that is found in the transport frame value. Then copy the transport frame value into the pseudo element during dispatching and then rely on the 'currentFieldExec' method as done in tutorial4.
2. Insert a 'pseudo' key into the bundled with a 'defaultValue'. Then iterate over all members of the variant during dispatching and compare the transport frame value to each defaultValue. Keep the member field selected that matches with the transport frame value.

Before this I modeled this variant with a sequence of 'optional' fields. While this is conceptually wrong, it did work because in the condition I can refer to the transport frame value.

I hope somebody could point me in the right direction. Should I stick with the 'variant' or go with the 'optional' values? If 'variant' is the way to go, how can I ensure that the variant member is selected based on information in the transport frame?

[arobenko]

Unfortunately at its current state the CommsChampion Ecosystem doesn't provide good means to deal with your specific use case.

After some consideration I would advise you to stick with the sequence of the <optional> fields. Although handling the values will require some boilerplate code, but I think it's a lesser evil. Doing what you need with <variant> fields is also possible, but it will require a custom code injection and it is very easy to make it wrong. Such approach will just move complexity and "manual" boilerplate code from one place to another, probably even increase it.

Just to give you an idea how to make <variant> based solution work, you need to perform the following steps:

• Make your <variant> field a global one to allow code injection.
• Extend the default field implementation with the .extend file.
• In the extended class there must be an ability to access the transport field stored in the message interface, i.e. there must be an extra pointer to the relevant field in the private data member. When message object is created, the constructor code of the latter needs also to be custom to set the pointer to the transport field.
• There is a need to fully re-implement read() and refresh() member functions ("manual" boilerplate code), similar to what is performed by the code generator (see tutorial4), but instead of reading the "key" field, access the transport field via stored pointer. The refresh() functionality also needs to update the transport field stored in the interface.
• The write() (and probably length()) functionality can be inherited, but will probably require using pseudo keyword on the "key" fields to prevent them to be written during the serialization.