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 <canvas> 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.