On 1 January 2014 20:46, Philippe Mouawad <[email protected]> wrote: > 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 :-)
Perhaps, but I think it would have worked just as well - if not better - if I had chosen to use BSF. > 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 need to learn from our mistakes. > >>> > 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.
