In many environments, it is desireable to dynamically monitor directories and files to examine for change. While it may be easy to perform a File.lastModified() call, the logic for monitoring the file is distributed throughout the different peices of code.
In 99% of the cases that need to monitor files, there are only specific files that must be monitored. In the Cocoon example, you have XSP files, sitemap files, and cocoon.xconf. In the Phoenix example, you have the configuration files themselves (and possibly the libraries). In the final solution, the monitored files must be able to be controlled. In most cases, if you have one background thread that is responsible for file monitoring, it can call the handler to take care of it. To begin with, that is probably enough. The files don't have to be monitored with less than a second granularity in most cases--and in production environments, will most likely be monitored in intervals of minutes or more. This approach greatly simplifies the need for alot of complex code in Cocoon that checks a file every request to see if it changed. In a busy server, that means that a file can be checked over 100 times a second during high traffic times. If the file is cached, that extra trip to the filesystem is unnecessary. The FileMonitoring system would enable you to notify the cache when there is a change--alowing the cache to be decoupled from the classes that check it. There are many uses for a Monitor implementation that could include FileMonitor, DirectoryMonitor, HttpMonitor, etc. The Monitor could feed cache systems, reconfiguration systems, and dynamic compilation systems. If the single background thread approach becomes a problem, we can use the ThreadPool approach and limit the number of threads to handle events to a small number--keeping system resources tame. The only problem is, I don't have time to implement it yet....
smime.p7s
Description: S/MIME Cryptographic Signature
