Last minute details….

After a lot of refocusing of priorities, the DVDDB release will be delayed for at least another few days. Lots of things have changed but I think for the better. As a one-man coding crew, I get done what I can when I have the time. The thing is, while not all of the stuff that is delaying release is needed now; however when it is needed I fear that I will not have the time to do it so and ounce of prevention seems prudent. The upside to this is that the API’s will be more stable on the back-end, the DVDDB will be far more secure and easier to manage and the whole project will be better-tested end-to-end.

First, I am still nailing down some functionality but a key change in this version is an added layer of security in the XMLRPC server. Right now in the current form anyone can add to and do lookups in the database. The back-end does have the ability to modify records, delete records, etc but with no security at all (outside of system security) it would be insane to expose those to the public. What I have in place and partially working is IP-based tiered access management. It still throws a shoe on occasion and that is one thing that has to be right before we turn the lights on.

Second, I am rearranging the database schema. They say experience is the best teacher; that may be true since using the back-end. When using the system in it’s current state I started seeing many other usage scenarios and if I can think of them, maybe others will too. As a result the main table will be just that: ID and disc title. From there the disc id will be used to query not only the tracks table as it does now but also a links table (imdburl is getting moved there) that could also be used to include vendor links, fan sites, etc. The following additional tables will be created: synopsis (ID, BLOB), trackdesc (trackID, BLOB) for individual descriptions (think show episodes), hbsettings for optimal HandBrake settings for this disc, reviews (ID, BLOB), and metadata (ID, genre, year, etc).

Next, I have made the decision to move the back-end from KirbyBase to SQLite. This is in NO way a poor reflection on KirbyBase; it has performed brilliantly. I could not have asked for more and would highly recommend it if you need a fast DB with no engine written in pure Python. My reasons for moving to SQLite now are that it is built into Python, I know SQLite can take a certain amount of punishment; Kirby may also but the time to find out that it cannot is not when you are under load. Since I will be writing code to rearrange the tables anyhow, this will be simpler than it might otherwise be. Also, I can use straight SQL with SQLite.

In the area of back-end maintenance I am revamping the tools for uploading DVD metadata to validate as much of the information as possible. The tool to fix a mistake in the back-end will involve either reusing an existing export file or one can be generated by querying the back-end. The resulting export file may then be edited and resubmitted.

To work then.

JeffC