BackendListener client design needs more work

[sebb <se...@gmail.com>]

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.

Would it not be possible to implement the Gui and sampler classes as
stand-alone classes?

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.
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.


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.

Re: BackendListener client design needs more work

[sebb <se...@gmail.com>]

On 8 February 2015 at 18:16, Philippe Mouawad
<ph...@gmail.com> wrote:
> On Sunday, February 8, 2015, sebb <se...@gmail.com> 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.

Yes, which is also not all that user  friendly.

> The limit comes from it genericity
> What do you find not easy to use ?
>

There layout is just a list of names ane values; there's no logical
grouping and no s
>
>> 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.

I meant listener, but in fact that won't quite work.
No matter, the main issue is that the Gui is not as easy to use as it could be.

>>
>> 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#createSampleR
esult 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.

I doubt it.

> 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.

Perhaps, though that is not very efficient.

>>
>> 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 ?

I don't know how long this will take.

I thought you were keen to get a release out soon.

Re: BackendListener client design needs more work

[Philippe Mouawad <ph...@gmail.com>]

On Sunday, February 8, 2015, sebb <se...@gmail.com> 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 ?