Hi, First thanks for having in mind to contribute a non gui recorder, by the way what is the use case ? My 2cents inline below. Thanks
On Wed, Aug 10, 2016 at 8:55 PM, Epp, Jeremiah W (Contractor) <[email protected]> wrote: > > -----Original Message----- > > From: Vladimir Sitnikov [mailto:[email protected]] > > Sent: Wednesday, August 10, 2016 2:10 PM > > To: [email protected] > > Subject: Re: JMeter DSL discussion > > > >> Hang on, why would you develop your DSL in a different language from > what > >> JMeter itself is actually written in? This wold seem to add an entire > >> new toolchain to the build process. > > > > Can you clarify what you mean by " different language from what JMeter > > itself is actually written in"? > > > > Do you suggest we should use java as a language to store JMeter test > > plans? I'm afraid that won't fly high. > > I thought he was suggesting implementing the language with Groovy, not > using > Groovy _as_ the language. And no, I'm not suggesting Java would work > better. Quite the opposite, in fact. > > > The entire point of a Domain Specific Langauge is to have precise control > over what you can and cannot do (semantics) and how it looks when written > out (syntax). It's a form of abstraction. > > >>> - how to express what today we can do through JSR223 languages which > >>> might be the most complex think to translate > >> > >> Is this really an issue? This seems orthogonal to the goal of creating > a > >> language to describe _test plans_ themselves. As long as this DSL has a > >> way to express the JSR223 sampler, saving the actual code that goes in > it > >> should go without saying. > > > > Jeremiah, you are missing a point here. Philippe means: "currently we > > have to use JDS232 samples to workaround limitations of JMeter test plan > > language". For instance, there is no support for "arrays" in the > > samplers, so one has to use JSR232 kind of scripts to work with arrays. > > > It's much more than that and it's IMO the big power of JMeter. Since I started writing JMeter plans, I have always had to write some part of it (correlation part) in JSR223+Groovy. Although over the years the volume of custom code tends to drop, I doubt it will be ever possible to express in a DSL all the possibilities. But what Vladimir has in mind is maybe to use a language (Groovy or other for example) and write in it a DSL for JMeter, in that case what I used to do with JSR223 might be possible with this language. But I am afraid it's a breaking change as he wrote it, I don't know how we would be able to handle backward compatibility and Gui compat. And using the GUI a lot (for example currently in a load testing mission) , I am happy to see that my productivity has even more increased with the new features. I am now definitely convinced that it is very useful. > > So, the quesion is "how to introduce control flow and data processing > into > > the DSL itself". Does it make things more clear? > > That does clarify, thank you. > > So the issue here is the current test plan implementation lacks important > syntax and semantics for end users. There are workarounds, but they are > kludgy and nontrivial. This is important information for designing a DSL. > > With that understanding, though, I'm somewhat worried that the actual > internal representation of a test plan is in question. I suspect changing > _that_ would be a considerable engineering effort. > > Before we take this line of thought any further, I think the actual desired > semantics of this DSL need to be hammered out. That is, what do people > explicitly _need_ to be able to do? > > Regards, > Wyatt > > Confidentiality Notice: This electronic message transmission, including > any attachment(s), may contain confidential, proprietary, or privileged > information from Chemical Abstracts Service ("CAS"), a division of the > American Chemical Society ("ACS"). If you have received this transmission > in error, be advised that any disclosure, copying, distribution, or use of > the contents of this information is strictly prohibited. Please destroy all > copies of the message and contact the sender immediately by either replying > to this message or calling 614-447-3600. > > -- Cordialement. Philippe Mouawad.
