DSL probably deserves a thread of its own, the thread was started in context of roadmap ideas. However, definitely agree it is not read only, just meant that there should be no intermediary (ie JMX)
On Thu, Jul 28, 2016 at 2:08 PM, Vladimir Sitnikov < [email protected]> wrote: > >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 > -- Richard Friedman 609.314.0129
