On Sunday, February 8, 2015, sebb <[email protected]> wrote: > I've just had a look at the BackendListener implementation. > [Sorry, I should have spent some time on this when it was first added.] > > Although it clearly works, it does not seem to me to be a particularly > user-friendly design. > The GUI is not very easy to use. > > it follows the same gui design as Java Sampler one. The limit comes from it genericity What do you find not easy to use ?
> Would it not be possible to implement the Gui and sampler classes as > stand-alone classes? Not clear for me, as I don't see sampler here. > > These can all derive from the same abstract parent class(es). > > == > > Also, it looks like the underlying BackendListener is duplicated for > each GUI Listener in the test plan. So each sample will be processed > multiple times, and there will be multiple queues. True but have a look at BackendListenerClient#createSampleResult which would be impacted by the redesign. Also not sure there will be more than 2 Listeners in a plan. If we create a good live listener (Graphite) + and good Post Test listener (Report generator) then it would be enough for most cases. That seems very wasteful. > > At the moment there is only one possible listener type so there is no > need to create more than one listener in a given scope, however in > future there will presumably be more. > > I think it would be better if the backend listeners were able to > register themselves with a single BackendListener which then > distributes the sample as needed to the eventual recipients. > > I've not looked into how this would fit in with scoped listeners; it > may be necessary to allow for muliple listeners, one in each scope, > and then allow for different listener types to be attached to the > different scopes. This needs further research. > > == > > Unlike existing Listeners, there does not seem to be any way to limit > processing to only successful/failed samples. > > Not sure this is needed . Backend implementation can do the filtering itself through createSamplerResult by returning null. > > I think the current implementation needs rethinking. > If it is to be included in the next release as it currently stands, I > think it needs to be very clearly documented as being subject to > change. > Can't you rework it before release ?
