Sasha, On Fri, Jul 17, 2009 at 7:19 AM, Alexander Berezhnoy<alexander.berezh...@gmail.com> wrote: > Andres, guys, > > 2009/7/16 Andres Riancho <andres.rian...@gmail.com>: >> Sasha, >> >> On Tue, Jul 14, 2009 at 3:34 AM, Alexander >> Berezhnoy<alexander.berezh...@gmail.com> wrote: >>> Hi list, >>> >>> I want to share with you my opinion about the current configuration >>> framework design (which is a result of developing the consoleUi and >>> current changing the gtkUi) >>> First, a summary: >>> >>> 1) Plugin instance you get from the core is not the same instance that >>> will be run => a bit misleading >>> 2) Plugin may return the option list, ok >>> 3) w3af core returns the option list too, but those are only the >>> changed options => misleading >>> 4) Options in the optlist have only getDefaultValue() method, even if >>> they represent the changed values => misleading >>> 5) To update some of the options for the plugin, you need to send the >>> optlist with all the options changed (not only recently changed). You >>> cannot say: update only this option to that value. => messy >>> 6) To get the current value of an option, you always get the plugin >>> instance and the changed options, and look what was or was not >>> changed. => messy >> >> I agree with all of your points, to sum up: core/plugin communication >> to setup plugin options sucks. >> >>> 7) Options may duplicate in the option list => ? >> >> I didn't know about this one! This should never happen, and it's not >> something I wanted. >> >>> So, my proposal (one of several possible) is: >>> >>> - Plugins are created in the exactly one instance >>> - Options are stored in their plugins and other configurable items, >>> never in the core. >>> - Every option is created in the single instance too >>> >>> Those assumptions would make the thing more clear, what do you think? >> >> I think it's a good idea, and not very complicated to develop. I'm >> thinking about a big dict in the core that holds all the plugin >> instances (hmmm, what about memory issues?), those instances are >> created only once, and by the w3afCore. w3afCore.getPluginInstance() >> would return instances from that dict. >> >> @Sasha: Do you see any issues with your solution? Is it perfect as it is? >> > > Well, there always can be issues. It may require a lot of places to change.
I think that this can be done by only changing the core and the user interfaces. Do you agree? > I will make a new branch on the next week and try the refactoring. Maybe you could do it in the same branch where you're changing the gtkUi? > Plugins, exactly as you say, will be the singletoned by the core. > All the configuration would happen through the use of their > "configurable" mixin, which will store the option descriptions and > their values as well. Yep, > Sasha. > >> Cheers, >> >>> Sasha. >>> >>> ------------------------------------------------------------------------------ >>> Enter the BlackBerry Developer Challenge >>> This is your chance to win up to $100,000 in prizes! For a limited time, >>> vendors submitting new applications to BlackBerry App World(TM) will have >>> the opportunity to enter the BlackBerry Developer Challenge. See full prize >>> details at: http://p.sf.net/sfu/Challenge >>> _______________________________________________ >>> W3af-develop mailing list >>> W3af-develop@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/w3af-develop >>> >> >> >> >> -- >> Andrés Riancho >> Founder, Bonsai - Information Security >> http://www.bonsai-sec.com/ >> http://w3af.sf.net/ >> > > > > -- > Alexander (Sasha) Berezhnoy, OSCP > http://sandals-on-my-head.blogspot.com > -- Andrés Riancho Founder, Bonsai - Information Security http://www.bonsai-sec.com/ http://w3af.sf.net/ ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
