Yeah I think it makes sense to use xml, considering that it’ll make it easy to generate from the existing tests.
Would be interesting to use something like https://graphviz.org/doc/info/lang.html so that we could more easily represent sequences. There’d also be a bunch of tools to visualise things as well. On Wed, 24 Aug 2022 at 5:52 am, Christofer Dutz <christofer.d...@c-ware.de> wrote: > Hi all, > > It’s getting more and more challenging to keep all of the driver types we > have in all the languages perfectly in-sync. > So I’m thinking of starting the next step on generating more of the code. > > Right now I’d love to generate the construction of well known messages. > As usually you have some messages that you send in certain situations. > There usually require you to fill 90% of the fields with constant values > and only 2-3 of the remaining are actually dynamic. > > So I’d love to generate a “message-factory” as a first step. > > There we’d have methods/functions like “createCotpConectionRequest” and > you only pass in the dynamic parts. This method/function would then simply > return a pre-initialized message that we can simply fire out. > > I think our mspec format just isn’t right for this sort of thing. I once > did a POC using XML and I generally liked it pretty much. > So in this case we’d use the format like we use in the tests, but with the > only difference, that for the dynamic parts, we could use placehoderrs like > “${someVariable}” and this would generate code that initializes the > data-structures for the given languages. > > What do you think? Sticking with XML for this, would make it more > compatible with our tests … we could simply take xml from our unit and > integration tests, and simply convert them into message templates. > > Chris > >
