There are some cool changes potentially coming from Luca/Dinesh and the usual bug fixes, testing, updating of text files etc., but the general shape of ntop 3.2 should be pretty clear from the cvs.
As part of this, some long over-due cleanup is going on. (C1) AIX and HPUX specific code was removed. Why? Because the last time any of this worked was ntop 2.2 or earlier and we don't have platform access. (C2) The -k option and other remnants of frameset technology have been removed. Yup, just when every browser out there can finally handle it, we are removing it. Why? Because with the new look/feel, we don't need it - in fact it gets in the way of a working page refresh. Much of this hit the cvs in the last 24 hours. Your assistance in testing (esp. those who are on less common platforms) would be appreciated. Coming soon: (C3) Single threaded ntop is going away. Why? Because single threading makes no sense. At it's core, ntop does two things which should not be coupled - processing packets and serving web pages. Things to do, maybe: (C4) Update myrrd to the recently released rrd 1.0.50... Given the problems with 1.2.x (it's gone through seven releases in two weeks - mostly trivial, but still hard to track a moving target), I think we stay away for ntop 3.2. (C5) Apple Rendezvous protocol. Luca is still looking... (C6) NetFlow - better filtering, more v9 handling QUESTIONS (speak now or hold your water...) (Q1) Is there ANYONE who has problems with Async Address Resolution? That is has to override globals-defines.h around 230: /* * Comment out the line below if asynchronous * numeric -> symbolic address resolution * has problems on your system */ #ifndef MAKE_ASYNC_ADDRESS_RESOLUTION #define MAKE_ASYNC_ADDRESS_RESOLUTION #endif (Q2) OpenBSD/NetBSD - AFAIK, these have NEVER worked right. Is anyone using them? It's not a lot of code, but there is some tests in ./configure I'm looking at pulling to simplify. (Q3) MinGW/Cygwin - anyone know the current (cvs) status of these? Note - we try and test ntop and make sure it works in environments our users use. The key to this is (N1) The development team has an interest in the platform AND (N2) The development team has access to resources for that platform. If and odd-ball version is important to you, we suggest you consider supporting the project via donations of time, money or resources (but remember, ntop requires root access to run and especially to test). Right now, we have pretty good access to various Linuxes, Solaris, OS X and Windows. More limited FreeBSD. That's it... -----Burton _______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
