On Friday, July 29, 2016, Antonio Gomes Rodrigues <[email protected]> wrote:
> My opinion > > The "github diff" is a false problem, users must use comment when they > commit diff in git is very useful. As a developer I highly use it, so I think it's a good point from Vladimir > > About users who don't like the GUI, a DSL is mandatory but not necessarily > the target of JMeter yes. > > About jsr223 XXX, if JMeter become a full DSL like > LoadRunner/Gatling/Grinder/...., we can remove all of them and use the > original language (Scala in Gatling, C in Loadrunner...) to add missing > functionality I don't think the target is to remove UI. I personnally think it's a big power of Jmeter and highly increased productivity of test development. DSL only is less productive. > > Thanks to the ruby-jmeter feedback > > @Philippe, do you want to replace GUI by a DSL or do you want to add a DSL > to JMeter? No , Keep improve UI but introduce dsl or compent first then dsl. > > Antonio > > 2016-07-29 13:06 GMT+02:00 Vladimir Sitnikov <[email protected] > <javascript:;>>: > > > >I think it ends up being a dsl anyway no ? > > > > It ends up being write only DSL. > > We can put whatever makes sense for humans, and do not care > > of the grammar/parsing stuff. > > > > The set of "printed" values/fields could even depend on the project. > > For instance, some kind of regexp for "exluded/included" header names so > > the output is both concise and useful at the same time. > > > > >Or does it in your mind work only from xml => comment > > > > As I stated in the comment itself, the comment is not supposed > > to be modified. Neither it is supposed to be parsed by JMeter. > > It is there for presentation purposes only, so dump views like "github > > diff" > > can make a basic sense of a file and show a decent diff. > > > > >If so it does not answer the requirement of some users to be able to > > change > > >the plan without xml format. > > > > I do understand that "pretty-printer in the comment" does not cover all > > the use cases. > > However, I think pretty printer will be both useful and easy to implement > > at the same time. > > > > my concern about language would be: > > > - its popularity , > > > - its easyness for users > > > - it's easyness to build dsls > > > - its future > > > > > > > I would add IDE support to the list as well > > > > > > > > > Groovy is ASF now also and it's already embedded. > > > > > > > This does not immediately solve "easyness for users" problem of Groovy. > > Have you seen Groovy puzzlers? > > https://www.infoq.com/presentations/groovy-puzzlers , > > > > Take a jsr223 preprocessor that has 4 to 10 lines of groovy code in it, > how > > > do you represent it ? > > > That's what I mean. > > > It can make dsl less readable. > > > > > > > Do you mean "abandon jsr223 in favor of a full blown programming > language"? > > Initially I thought you wonder how to add "a jsr223 preprocessor" when > > using some kind of DSL. > > > > When using a programming language, some kind of IDE is required to craft > > the script. > > > > I find "http sampler" rather hard to express in DSL so it is readable. > > > > > > > > > look at ruby-jmeter it does a nice job at doing that > > > > > > > ruby-jmeter implements just a small subset of the options that can be > > configured in JMeter UI. > > It will hardly be that much readable when order options are > > implemented/used (e.g. lots of parameters passed to the application). > > > > Vladimir > > > -- Cordialement. Philippe Mouawad.
