*Navigation trail:* \["JMeterProjectPages"\] - \["JMeterDevelopment"\] Wiki Markup
...
Enhancements - again, what's the advantage of this over the bug database? The database is sufficient for simple enhancement ideas like these. (Mike Stover 2003-01-07)unmigrated-wiki-markup
The intention here is to try to go beyond the small enhancements and try and work out what features we want to target for the next release. The first step is to dump our ideas here, we can then try and organise them into some kind of logical grouping and try and decide which ones go in the next release (or the one after, and so on). The structure is kind of working itself out on \["JMeterDevelopment"\]/LongTerm - we should remove things from this page as they are moved to \["JMeterDevelopment"\]/LongTerm (this means that I have some cleaning up to do) and enter the remaining ones in bugzilla (presumably they will be too small and isolated to warrant discussion in the long term development context). -- [ScottEade] – ScottEade 2003-01-11
- "Server Sets" and logical servers for HTTP/FTP/SOAP requests to make switching between server environments (test/production) easier – OliverRossmueller 2003-01-06
- Instead of (or on addition to) "Server Sets", we could move the variables table outside of the Test Plan, putting them in their own test element. Then we could just move the right variable set in and out the test to switch servers (or any other configuration) – JordiSalvat 2003-01-15
- Make the workbench a real workbench where you build your tests, test them and add the to a test plan as soon as they are doing what you expect them to do – OliverRossmueller 2003-01-06
- Support for compressed datastreams (specifically using gzip and other protocols). Many servers and browsers support this and it would be nice to evaluate the 'compressablity' of a site using jmeter.
- Keep track of major tree modifications so that an "undo" can be implemented. arnaud 2003-12-01
- Think that there should be an option to run test plans as "stress tests" so that the number of threads would slowly increase (by user configurable amount in a user configurable time period) until the server's response time would reach a certain limit or a configurable limit of errors would be reached. Would be handy to determine the maximum capacity of a server (joonas dot lyytinen at iki dot remove this fi)