> The idea of having a central program monitoring all client requests may > sound fine, but is totally unrealistic (at least, with the manpower we > have). Um, is it? <thinking mode=aloud> wpkg.js has a function which displays debug messages to screen or event viewer. Could that be adapted to optionally open HTTP connections? We might assume that the wpkg file server has an httpd running and so making connections like: http://wpkg.server.org/wpkg-log.php?client=%HOST%&message=Installing%20Word could be made. If we felt so inclined, this could be logged somewhere nice like an SQL database but even doing nothing with the data other than logging it in the httpd access logs would provide useful information for people to grep. The actual wpkg-log.php doesn't need to return anything and wpkg.js doesn't need to do anything with the returned data (if any). If the page is 404, who cares? Data will just get logged to error_log instead. If the httpd isn't running, we'll have to wait for a TCP timeout for each connection attempted, which is a bore but not a show-stopper. A command-line option could be /httplog=http://wpkg.server.org/wpkg-log.php - if set, try http logging. If not, continue as normal. </thinking> Just a thought... F |