On Sun, Mar 8, 2009 at 3:15 PM, Luis A. Bastiao Silva <[email protected]> wrote: > On Sun, Mar 8, 2009 at 5:56 PM, Guilherme Polo <[email protected]> wrote: >> >> On Sun, Mar 8, 2009 at 2:34 PM, Luis A. Bastiao Silva >> <[email protected]> wrote: >> > Hi. >> > >> > On Sun, Mar 8, 2009 at 5:03 PM, Guilherme Polo <[email protected]> wrote: >> >> >> >> On Sun, Mar 8, 2009 at 1:02 PM, Luis A. Bastiao Silva >> >> <[email protected]> wrote: >> >> > Hi all, >> >> > >> >> > I'm making a effort to port NSE Facilitator to be a plugin. >> >> > Maxim Gavrilov doesn't maintain the branch anymore, so I was thinking >> >> > why >> >> > couldn't bring NSEFacilitator as plugin? Nobody made a plugin really >> >> > useful >> >> > (I'm excluding the Flow Analyser and GeoLocation/traceroute at >> >> > PacketManipulator, and others nice but don't really usefull in nmap >> >> > context). So NSEFacilitator will be, so we give the real value to >> >> > Umit >> >> > Plugins. >> >> >> >> I would like to hear the reasons for transforming the NSE Facilitator >> >> into a plugin first. Does it make sense to make it a plugin ? >> > >> > Fair enough. >> > I'll show a perspective. But I want to clarify: This is just a >> > hypothesis >> > :-) >> > >> > NSE brings to users the a powerful and *extensible* way to add new >> > features >> > to search networks and make sophisticated detections. >> > >> > If it is extensible, current user couldn't need this. So why they needs >> > NSE >> > Facilitator? >> > >> >> Huh ? If it is so powerful and so extensible that is yet another point >> to not make it a plugin. >> >> If it is extensible as you say, then it already has plugins (its >> extensions). Which sounds like another point to not turn itself into a >> plugin. >> >> > >> > But I'm not sure about that.I'm aware if we integrate it to umit package >> > we >> > could easily use the module if it necessary and maybe will be in right >> > side. >> > >> >> Uhm ? >> >> > Plugin or not plugin sounds good to me know if NSEFacilitator is ready >> > to be >> > on 1.0. >> > >> >> I'm not sure if it is good to add it to 1.0. There aren't many people >> (by many you can consider 2 or 3 people here) taking care of the >> "standard umit", so who would take care of NSE Faciliator ? > > > Yeap. I agree. > Sometimes I fly and I think that we can just make all the stuff. > We should concern in take care of what Umit have firstly before include new > features. > > But what is your definition of what should be a plugin? And what shouldn't? > >
Well, given how umit is structured I don't think nse facilitator makes sense as a plugin. I don't have a concrete definition about what could be turned into a plugin and what could not, but in a different project most things we have could be a plugin -- I will leave to someone else decide if it is better or not. SMTP Setup could be a plugin; The Scheduler log could be a plugin; The GUI interface for starting/stopping the scheduler could be a plugin; The Scan Scheduler Editor could be a plugin; The Scheduling Profiles Editor could be a plugin; Parts of Network Inventory could be a plugin (the graphs for example); The standard Diff viewer could be a plugin; The Nmap scan output coloring could be a plugin; Profile wizard could be a plugin; And several other things could be a plugin. But this all doesn't make sense right now, not in umit at least. -- -- Guilherme H. Polo Goncalves ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
