> On balance I think this is mostly very positive and forward > progress.
Me too. </aol> > > Proposed Strategy: > > In order to solve this problem, the monitor scripts will have to pass more > > data back to Mon. However any changes to Mon and the scripts should > > probably try to be backwards compatible. > > I won't quote Yoda here, but I will say that backwards compatibility is > pretty important, especially for a product in as wide use as mon. > > Also be aware that if you present different monitor formats, you risk > forking monitor development. As the maintainer of the mon contribs, I'm > particularly sensitive to this. A possibility might be if the monitors > defaulted to the old style, and were patched to allow an '--extended' > mode, but that is a lot of work. This may or may not be a good idea: how about versioning the monitor output format? Possibly the extended format will needs some tweaks. Would we create a new "super-extended" format? The current mon format is similar to HTTP 0.9: no version information given in the output. The next version (1.0?) would require each monitor to put something like Monitor format: 1.0 As the first line of the output. Simple, eh? Calling different routines in mon to parse the output would simple too: look at the first line. If it matches /^Monitor format: ([0-9]+\.[0-9]+)$/ then switch on the value of $1. Otherwise, assume it is a 0.9-formatted monitor. Alas, doing this may not mesh with the rest of the mon framework. -- Mark Wagner [EMAIL PROTECTED] 206-598-0302 Unix System Administrator, Radiation Oncology and Radiology _______________________________________________ mon mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/mon
