On Wed, Jan 1, 2014 at 9:43 PM, Philippe Mouawad <[email protected] > wrote:
> > > > On Wed, Jan 1, 2014 at 9:41 PM, sebb <[email protected]> wrote: > >> On 1 January 2014 20:28, Philippe Mouawad <[email protected]> >> wrote: >> > On Wed, Jan 1, 2014 at 8:04 PM, sebb <[email protected]> wrote: >> > >> >> On 1 January 2014 15:08, Philippe Mouawad <[email protected]> >> >> wrote: >> >> <snip/> >> >> >> Seems to me all this could be done by having a generic interface to >> >> enable the raw results to be saved to whatever backend is required. >> >> >> > >> > We could refactor code in the following way: >> > - GraphiteListener => BackendListener >> > - Introduce Backend Interface >> > - Backend would be called in testStarted/testEnded and within the >> existing >> > run() to send metrics >> > - There would be a select box to select backend. Backend implementations >> > would be searched within classpaths >> > - Graphite part and PickleMetricsManager would be moved to Graphite >> Backend. >> > >> > We could after that add a JBDC Backend. >> >> That sounds a lot better. >> >> >> >> >> What I don't agree with is yet more code that is very specific to a >> >> single 3rd party software solution. >> >> >> >> Whatever is added needs to be >> >> - generally useful to the JMeter population. Niche requirements should >> >> be met by 3rd party add-ons developed for the purpose. >> >> - use a generic API, for example like JSR223, JDBC etc. >> >> >> >> I understand your wish but take the history of JMeter. At some time >> there >> > was a need for custom scripting but no standard like BSF of JSR223. >> > So you selected Beanshell . Once standard was introduced we moved to it. >> >> Actually, I think BSF was available, but I did not know about it. >> > So you chose a popular third party at that time, and you did very well I think if you look at JMeter history :-) I think we should accept to make the best choice at the time the choice is done, not the best theoretical choice :-) >> > I think we cannot wait for all standards to exist, for example if we >> take >> > NoSQL Databases, it is hard to tell when a JDBC equivalent will be >> > available, does it means we should >> > wait until they are available ? I don't think so. >> >> If there is no standard, then we need to look very carefully at what >> JMeter needs as regards an API. >> We should define an API to suit JMeter which can then be implemented >> for specific NoSQL implementations. >> >> It does not have to be a fully fledged NoSQL API - in fact it should >> probably not reference NoSQL at all, but should allow the repository >> to be JDBC as well. >> >> Sorry my note was kind of out of subject, it was refering to last Redis > discussion. > Regarding the Backend discussion, of course if will be totally > independent, could be file, jdbc, jms, no sql, graphite ... > > >> > >> >> > >> >> > >> >> >> Regards, >> >> >> Vladimir Sitnikov >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Cordialement. >> >> > Philippe Mouawad. >> >> >> > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > > > > -- > Cordialement. > Philippe Mouawad. > > > -- Cordialement. Philippe Mouawad.
