Hello,
  First of all, I should be releasing a new version of JFFNMS shortly,
it has taken much longer than it should of to get there.

In the future, I will be dramatically changing the way JFFNMS works.
You probably cannot imagine how difficult it is to maintain and release
JFFNMS.  I've written Free Software since 1994 and its the most painful
project to release and debug.

The main problem with it is that the programming language is PHP. It's
pretty good for websites (I use it for that on my own website) but is
not so good for applications.  It's also difficult to work out what is
source and what should be released.

Another problem is the state in the database.  I need to juggle many
databases just to make the program work, without customisation.
sometimes, and this database version control problem is what broke in
the last release.

OK, so that's the current problems, what will the new JFFNMS look like?

 * It'll be written in C.  Initially this will be the back-end (pollers
etc) but eventually most of it will be in C.  I don't imagine that the
front-end won't because writing web pages in C is unbelievable painful;
it will probably stay as PHP.  What will change is how it works with the
rest of the program.  Take logging in for example, the web code actually
does the login check, eventually this will be some front end that sends
the username and password through a IPC to the backend which decides to
let you in or not. IPC's can be easily changed to work over networks, so
the webserver could be different to the application server.

 * The interface type, graphs etc definitions will be in a or many
configuration files.  You won't have to know PHP to make your own
interface types. This will save on development time so much because a
lot of it is integrating and updating new interface types.  It will also
mean that if you have a neat new interface type you want to share, you
just give it to your friend, who puts it into say /etc/jffnms/conf.d/
and away you go. It means the definitions in the database will go
eventually, but the *instance* of a interface will remain.

 * There will be more, or perhaps more flexible, pollers and discovery
agents. This is to permit you to put all the definition into a config
file. They will be, as much as possible, generic and not specific to
anything.

 * To handle its expanded duties, the configuration file layout will
change.  It will be hierachial and probably will look something like a
dhcpd or bind configuration file; or maybe even junos-ish.

 * The version control will move to git. I've converted most of my other
projects to using this and it works great. If you don't know what CVS,
SVN or git is; ignore this paragraph :)

 * It will most likely use glib and libraries like it. I'm not going to
re-write a queue, string or hash handling functions when glib does that
perfectly fine.

  * It will be developed on Linux.  I don't see why it won't compile on
Windows but I'll need someone to test this and most likely sort out the
windows-specific things.

 * Once the main changes are completed, I'm going to write a proper
correlation engine because most of them out there are pretty bad.

Once I've got the last PHP version out, I'll be calling for volunteers
in helping me on this.  You could know C, or perhaps you have some good
ideas about how the configuration files should look like. Or, further
down the track you like PHP and can work on templating the front end.

This should give us more stable and more frequent releases.  It's a lot
easier to find compile-time and run-time bugs this way.  I'm also hoping
it will help out larger installations out there.


 - Craig

-- 
Craig Small    GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                           csmall at : enc.com.au
http://www.debian.org/        Debian GNU/Linux, software should be Free 



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
jffnms-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jffnms-users

Reply via email to