I'm a long-time user of BigBrother, which I still love and use, at least for as long as I can. That said, I'm one to embrace change. I'm a fan of this idea, which I think also has other benefits, e.g., the ability to collapse child events and only show parent events when viewing history / summary using in-game commands. I would highly recommend PDO, at least from a practical standpoint. PDO comes standard with newer versions (5.1+) of PHP, which should reduce the number of dependency libraries; supports many native database drivers (SQLite, MySQL, PostgreSQL, MS SQL among others), which—as long as we stay away from any database-specific features—should allow users to use whatever database is available on their system; and using PDOStatements, it certainly makes it easier to secure against SQL injections by using bound columns/values. What about separating the LogBlawk PHP API into a standalone library that is separate from both the web interface and web stats pages? Both the web interface and web stats would then be regular web applications that happen to use the LogBlawk PHP library. This way, if people aren't forced to install the web interface if all they want is to use the PHP API. I've not contributed much to open source projects before, but I'd like to help out where I can in this project. I've been using PHP and MySQL professionally since 2004, and personally a few years before that. I'm not good with making pretty and fancy graphics, but I can do simple and minimalist interfaces, and I'm even better with incorporating existing designs. I've been using jQuery for a couple of years now, and Prototype.js a couple of years before that; most of it through my use of Rails, but it doesn't mean I can't use jQuery directly. I also have experience with Java and Swing; while I've used Java in professional work, I've only dabbled with Swing. I do understand wanting to make the migration process as user friendly as possible; however, personally, I prefer a good old simple command-line script or two, written in a scripting language like perl. To me, it's important that the migration tool be able to run on a headless environment, and—while I realize I might not represent most users—a GUI isn't a priority. I wasn't sure how much of a time commitment you're looking for, and mainly what timeframe you're looking to get a first version out. I'm sure you hear enough promises of kittens and rainbow from people saying they'll commit to 80 hours a week, but then don't hear from them for two months; instead, I'd be interested in starting out with taking on smaller, more well-defined tasks, and then submitting patches (or pull requests if y'all are GitHubbers). I'm not sure how this fits in the grand scheme of the schema, but are there plans for a separate "actions" lookup table (e.g., lb_actions), which maybe maps an internally-used action ID, the fully-qualified class name (reflection support for rollbacks), and a human-friendly name? The reason for this is that I—and perhaps some others—would appreciate the ability to define custom actions that aren't lumped into an "Other" entry. For instance, I have a small plugin that allows my players to "paint" blocks (left-click block to copy, right-click to paste) à la VoxelDoop's Paintbrush Tool. I loved BigBrother's custom Action and ActionProvider, which I used to log these "paint" events. It's a pretty specific use case, but it's certainly a feature I appreciated. To roughly illustrate: Code: id | class_name | name 1 | net.logblawk.lb.actions.BlockBreak | Block break 2 | net.logblawk.lb.actions.BlockPlace | Block place . . . 24 | net.logblawk.lb.actions.BucketUse | Bucket use 25 | com.hcblue.mc3.slimer.BlockPaint | Block painting <-- Also, I do like the name Guardian (plus, it doesn't have any similarity in name to BB, LB, or HE).