The Problem
The HTML visualization
was originally written just for my own debugging purposes rather than as an adminstrative tool. This visualization has proven to be popular and generated some excitment for the Bouncer project (to see an example, click on the attachment below).
I am somewhat uncomfortable using it as a production tool for these reasons:
- The Bouncer programs have a pretty clear division of labor. User interaction is done using programs written in PHP. Sentry is a behind the scenes tool whose mission was not conceived as making presentations to the user.
- Sentry uses a complex and arcane templating language to render the HTML. Since it was a debugging tool, I used a template language that I had at hand rather that what would have been the best choice. While there are other tools that Sentry could use for generating HTML, why should the project have more than one system for generating HTML? PHP is a much more logical language for generating HTML content.
- Sentry produces static HTML rather than dynamic content. Not only does this unnecessarily use disk space, but it introduces more configuration options that complicate setup. How does the user find these HTML reports? Does Sentry write them to an external location that is accessible to a Web server?
- Sentry stores persistent data about each test run in a file solely to assist in producing the HTML. Again this is a complication to configuration.
Proposal
Modify the database so that the results of each test by Sentry are saved in the database. The current Sentry visualization could be generated dynamically using PHP instead.
The new table would have this schema:
sentry_test {
sentry_test_id: int; #auto-increment
downloadable_id: int;
sentry_test_result: varchar(255);
sentry_test_timestamp: datetime;
}
We'd also need a way to clean up old data in this table. We don't want to keep logging data forever: perhaps an age threshold.
We'd also need to make sure that SQL deletes on the 'downloadable' table would cascade to this table.
Discussion
There are several advantages to this proposal.
- There would be only one language used for Web presentation. This simplifies future maintenance.
- Since the base data would be in the database, other future analysis tools will have access to the data.
- We've separated behind the scene work from presentation.
While we agree that this is a good suggestion, perhaps it should wait for the next version of Bouncer - we need to get this software out the door.