>I think step 1 is a DSL which can be read by JMeter 1) In my point of view, "read only DSL" does not work. There should be a way to generate that DSL.
Then the question comes to: "should that DSL be the master source of the script"? Suppose Kotlin is chosen for DSL language. What should JMeter do if it finds "for" loops in the jmx script? Of course it could read it somehow, but it would be way harder to write the same script with all those "for"s/"if"s from UI. JFY: TeamCity 10 introduced Kotlin-based DSL for build scripts: https://confluence.jetbrains.com/display/TCD10/What%27s+New+in+TeamCity+10.0#What'sNewinTeamCity10.0-DSLforTeamCityProjectConfiguration Frankly speaking, I've no idea how TeamCity plays with "for" kind of elements in the build script. 2) Take "HTTP Sampler" as an example. How would you express that in DSL? It could easily span several screens, so it would be hard to create manually => it would not be practical to "write that manually". 3) DSL approach seemed to work well for Jenkins, however it is rather hard to keep "DSL language" and plugins in sync. The DSL will become plugin-version specific, etc, etc. Vladimir
