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....
S/MIME Cryptographic Signature
