(I'm splitting the responses to keep the threads pure) And:
We need to get away from the memory structures from H*ll Use a real in-memory database with a (persistent) backing store instead of re-inventing the wheel We need to get away from C and the pointer arithmetic from H*ll C#? We need to get more modular so people can pick and choose to install only what they need. (And an architecture that allows for solutions to specific problems without global ./configure options) We need to get away from supporting every odd bit of kit that comes along with #ifdefs (AIX?) We need to get away from the configure file from H*ll Do the tests and if something isn't installed properly (i.e. accessible to a standard AC_CHECK_FUNC or AC_CHECK_LIB), we simply disable that feature. None of the looking in 37 places to find it. We also bounce the gdchart0.94c stuff - which means we need to make ntop work with an available version of gdchart. I'm starting to believe that ntopNG needs to be a total re-write as a modular plugin/event architecture. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Luca Deri Sent: Friday, April 04, 2003 2:25 AM To: Burton M. Strauss III Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Rocco Carbone Subject: [Ntop-dev] Re: fork(ntop) Burton, the fact that this patch does solve a *specific* problem is the problem. I don't want to see into the code fixes for specific problems. Futhermore if somebody has a specific problem I don't see why everyone must be affected by this. In addition, why this patch is only for NetFlow? Why not for the basic ntop, for sFlow and others? The same applies to the white/black list addition. <snip/> Concerning the development ideas I read below all I can tell you is: 1. ntop needs to be futher simplified 2. ntop needs to be able to scale at Gbit speed 3. data persistency should be improved Luca _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
