Besides adding features and fixing bugs, there are some maintenance tasks we need to do for WebKit. These are things we talk about all the time on the IRC channel, but some of them take a long time. I thought I'd make a list here of some of the big ones: - remove all uses of Deprecated classes and then remove the classes themselves - finish renaming `kjs_xxx` files in `WebCore/bindings/js` to more sensible names - move things defined in WebCore but in the KJS namespace into the WebCore namespace - do the planned renames in the `do-webcore-rename` script - reorganize JavaScriptCore to a "class per file, named after the class" organization - fix formatting of JavaScriptCore to match normal WebKit standards - rename the KJS namespace to JavaScriptCore - finish code moves from `Frame` to other classes (documented with comments in `Frame.h`) - change `CompositeEditCommand` and `EditCommand` to separate classes (not derived and base any more) - restructure undo handling for edit commands so that the the number of different types of undoable steps is smaller and they have much smaller granularity; we can write more robust versions of them - eliminate raw pointer use in favor of `RefPtr`/`PassRefPtr` - move `ref`/`deref` classes to the "start with 1" rather than "start with 0" approach - fix `config.h` situation The `config.h` file really only exists for platforms that don't have a "prefix header" mechanism. 1. On platforms with a prefix header, it should only have enough contents to make sure you get an error if you forget to include it. 2. Common things that need to be included everywhere should be in a separate header, which should be included in the prefix header on platforms that have it, and in `config.h` on platforms that don't. 3. We probably shouldn't have a shared cross-platform file named `config.h`. For example, people building with autotools will want to use it to create `config.h`. - fix platform `ifdefs` that are sprinkled around instead of being concentrated in the platform directory It's okay to have platform-specific code anywhere there's a good reason, but `` is a good example of how '''not''' to do it. - rationalize top-level platform names Need a name for the Windows CoreGraphics port and the Windows Cairo port. - bindings wrappers take too long to compile Should we compile as one giant source file instead of individual files for speed? - apply style guidelines more consistently to existing code - fix all header guards to match filenames by running `clean-header-guards` - move Objective-C bindings generation into Mac WebKit - move code that doesn't belong in Mac WebKit into WebCore - move code that doesn't belong in WebCore into Mac WebKit Make the core Perl script modular enough that the Objective-C stuff can live in WebKit. Eliminate the scripts that copy all the headers. There's still a lot of crap in there that can be moved down. WebKit is for binding to the Mac API and to Objective-C. Things like the Objective-C accessibility wrappers should be in WebKit, with a C++ version in WebCore.