On 30 August 2015 at 14:59, Felix Schumacher <[email protected]> wrote: > Am 30.08.2015 um 13:47 schrieb sebb: >> >> On 30 August 2015 at 12:07, Felix Schumacher >> <[email protected]> wrote: >>> >>> Am 30.08.2015 um 12:33 schrieb sebb: >>>> >>>> Thanks for the bump. >>>> >>>> As mentioned in the thread, it would be useful to have a Wiki page or >>>> SVN document (or several) where the ideas can be fleshed out. >>>> In particular, the architecture rework and shared samplers would have >>>> a major impact on the design and 3rd party samplers, as well as being >>>> a lot of work. >>>> >>>> I am always more wary about changes that affect the whole of JMeter >>>> compared with new test elements. >>>> This is because the knock-on effects are very difficult to forsee. >>>> I think we tend to underestimate the amount of work needed to complete >>>> a feature, for example Undo/Redo. >>>> Optional addons are less of a risk, but of course still need >>>> documentation, maintenance and user support. >>>> This is why I have often been resistant to new features that are >>>> relatively specialised. >>>> >>>> I won't comment on individual features here because the thread will >>>> get impossible to follow. >>> >>> There is already a (very old) page with ideas to implement >>> (https://wiki.apache.org/jmeter/FutureReleases) which could be a starting >>> page to fetch up with the current state of jmeter. >>> >>> I think a svn based plan would be nice, too. As it would be a bit more >>> official. Something like roadmap.txt in the main dir? >> >> I think it would be better to have it in a separate part of SVN, not >> as part of trunk (it's not intended for release) >> It could be under branches, or it could be top-level. >> Just not tags nor trunk please. >> >> Also there should be a single page for each idea. > > I think it branches is not the right place, since I expect complete branches > there. So a top level would be more appropriate, but it still feels wrong to > me.
Since it is meta-information for the whole project, and not version-specific, it seems fine to me. There is a PMC only SVN area also but that is private. > Maybe place (hide) it inside xdocs? No, that's not appropriate as it will still be released. Also it applies to all future releases, not just current trunk. >> >>> I would try to update the wiki page, but my (newly created) account >>> "fschumacher" is not allowed to change anything :) >> >> Should be able to now. > > I have added the ideas to the page FutureReleases. They contain links to > pages where discussion on each idea can take place. > > The list has not been updated since 2009, so there will be quite a few > things, that jmeter is capable of by now and can be removed. > > Regards > Felix > >> >>> Regards, >>> Felix >>> >>>> >>>> On 30 August 2015 at 07:34, Philippe Mouawad >>>> <[email protected]> >>>> wrote: >>>>> >>>>> Bumping for sebb as he requested it in another thread. >>>>> >>>>> >>>>> On Saturday, January 31, 2015, Philippe Mouawad >>>>> <[email protected]> >>>>> wrote: >>>>> >>>>>> +1 for all your suggestions. >>>>>> >>>>>> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher < >>>>>> [email protected] >>>>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> >>>>>> wrote: >>>>>> >>>>>>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad: >>>>>>> >>>>>>>> Hello, >>>>>>>> I think it would be a good idea to fix a roadmap for next releases >>>>>>>> of >>>>>>>> JMeter so that we can concentrate our work on prioritary features. >>>>>>>> >>>>>>>> My prioritary ideas are the following: >>>>>>>> >>>>>>>> - Rework architecture to be able to use a pool of threads >>>>>>>> instead >>>>>>>> of >>>>>>>> thread or use Reactor Pattern ( >>>>>>>> http://reactor.github.io/docs/api/reactor/timer/ >>>>>>>> SimpleHashWheelTimer.html >>>>>>>> ) >>>>>>>> >>>>>>> Maybe we could/have to convert the test elements to take a context >>>>>>> instead of cloning them for every thread. I believe we can save a lot >>>>>>> of >>>>>>> memory that way. I think we have to do something in this respect. >>>>>>> >>>>>>> - Introduce Http Client async feature or at least use one >>>>>>> HttpClient >>>>>>>> >>>>>>>> for >>>>>>>> all threads >>>>>>>> >>>>>>> I think it would be nice to have parallel http requests for one >>>>>>> thread >>>>>>> (simulated user) to be able to simulate the requests of a browser >>>>>>> more >>>>>>> accurately. >>>>>>> >>>>>>> - Support Websocket and SPDY2 (bugzilla for those, but they >>>>>>> depend >>>>>>> on >>>>>>>> >>>>>>>> first 2) >>>>>>>> - Create an Async listener + a pluggable one (to allow >>>>>>>> Graphite >>>>>>>> /JDBC >>>>>>>> plugins) , see https://issues.apache.org/ >>>>>>>> bugzilla/show_bug.cgi?id=55932 >>>>>>> >>>>>>> >>>>>>>> . I made progress but didn't commit work yet >>>>>>>> >>>>>>> Done since then >>>>> >>>>> >>>>>> - Fix known bugs in REDO/UNDO new feature >>>>>>>> >>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043 >>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039 >>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040 >>>>>>>> - Fix >>>>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53540 >>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833 >>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628 >>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597 >>>>>>>> >>>>>>> Another thing I think we should consider is a StreamProcessor, which >>>>>>> can >>>>>>> be used to look/modify the results of a sampler as they happen, >>>>>>> instead >>>>>>> of >>>>>>> a PostProcessor, which gets all the data after the sampler has got >>>>>>> it. >>>>>>> That >>>>>>> would enable us for example to compute the md5 sum for large >>>>>>> streaming >>>>>>> data, or validate that streaming data, without using too much memory. >>>>>>> >>>>>>> I would like to see more imap sampler possibilities, like quota, >>>>>>> status, >>>>>>> search to be able to put an imap server under load. >>>>>>> >>>>>>> There is a wiki page which holds a "roadmap", should we update our >>>>>>> ideas >>>>>>> there? >>>>>>> >>>>>> Yes good idea. >>>>>> >>>>>>> Regards >>>>>>> Felix >>>>>>> >>>>>>> >>>>>>>> I suggest everyone enhances this roadmap and we vote to decide on >>>>>>>> the >>>>>>>> priorities. >>>>>>>> >>>>>>>> Thoughts ? >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> Cordialement. >>>>>> Philippe Mouawad. >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Cordialement. >>>>> Philippe Mouawad. >>> >>> >
