Hi Together, Having worked now on golang for a while and jumped back to java I saw that we had many similarities between the languages. First of all the structure if message being sent (e.g. during the S7 connection dance) and the conversations happening (e.g. during the s7 connect). So it feels more and more like and extension to our current code generation:
[Stage 1] At the moment we are in Stage 1: - We can generate Typed structure into the languages from mspec (The definition of what is contained in an instance of a message) - We can generate „how“ the message is serialized on to its primary medium In byte form (xml, string, etc will be decoupled soon from these models, as they currently re-implement the [de]serialization in a different format [first fruits from that already in develop]) - We can generate some known constants from mspec At this point we have at least a reproducible serialization between languages (assuming the templates are correctly implemented). [For that I also have began changing the way xml (un)marshaling works which will replace the current one soon which I will talk about more in a later mail] [Stage 2] We can generate Message instances in a template like code - also a sister spec - Taking S7 for example: during a connection initalization you need to send 3 specific defined messages (with potential little variation) to the plc. These messages need to be re-implemented in every language the same way - Defining a sister-spec beside *.mspec we could define these message with placeholders and generate a MessageTypeFactory from this to create known messages. - Another example is the ADS symbolic addressing where you send a well defined message and get the response for the index offset in the response. [Stage 3] We can generate an interaction for a ping-pong - also a sister spec - e.g. Sending request x with parameters x1, x2 we expect response with value z1,z2 - defining this we could define a simple request/response and generate code from that [Stage 4] We can generate an conversation - also a sister spec - going back to the s7 connection dance, we could possible using the features from the stages before define a whole well defined flow: „Send COTP Connection Request->Receive COTP Connection Response->Send S7 Connection Request->Receive S7 Connection Response->Send S7 Identification Request->Receive S7 Identification Response“ - at the moment we do something like this already in our driver test suites but we don’t generate code from that. [Stage 5] We can define properties and options - at the moment we need to reimplement necessary options and parameters in every language again. e.g. AmsNetId, S7-Rack and so one. - defining known and required options we could generate configuration parsers in every language [Stage 6] World domination - We ran out of stages and there is nothing more left to do for plc4x :o) So now as the wall of text has ended I would be glad to get some feedback and ideas on the above points. Disclaimer: points above came up while having a fruitful OTR discussion with Chris. So credit where credit is due :) Sebastian
