Just a quick post on some thoughts for the architecture for the revision of the utility.
Architecture
One of the purposes of the rewrite is to make the utility more flexible. Currently a user is required to have a fairly modern browser with JavaScript enabled and the RealPlayer plugin to use the utility to it's fullest potential. Ideally the utility should have a base level of functionality even in the most crippled of browsers. One way to get to this level of functionality is to use progressive enhancement to add enhanced functionality through JavaScript on top of an already functional HTML core.
The way I envision modeling the utility so that this can be acheived is to go back to a classic three-tier system: presentation, logic, data. By further extracting the functions that handle data processing from flow control and interface presentation I hope to be able to create a functions that can response to requests from a variety of sources (rather than using conditional statements to determine the output). I imagine the easiest way to do this is to develop the functions as discreet scripts that process requests and return XML over HTTP (similar to web services I suppose). That way the interaction of the front end to the back end does not depend on the the source (browser vs. server script), allowing the backend to be simplified somewhat while allowing the front end to branch out.
I also think that modeling the utility in this way will make updates simpler. The difficulty of editing the processing page gets worse over time.
Video
I've posted recently on problems with the timecoding, so no need to go over that again. Another issue, though, is that I'd like the video portion of the utility to be less restrictive. The utility should be able to handle formats other than RealVideo and players other than RealPlayer. If the security issues can be addressed and the object model of the players determined then it should be fairly trivial to determine which player to use at runtime.
Security
One of the biggest problems with the current utility is it's security. The authentication system is ugly and not too secure. The user rights assignements are too broad. There's no way to sandbox users beyond limiting their rights (e.g. limit the Deleware group admins to administration of their own users).
I'm thinking that to work around this I'll create a permissions table that stores information on who can perform what functions. This should allow a finer level of authorization control. One area that I hadn't originally thought about until just now is the sandboxing of users ... something I'll definitely need to consider.
