>>73
Eh. I don't want another Kusaba-incident wherein bad code perpetuates despite the author's intent to remove/replace it. Plus, I think I learned a few things from building matsuba, and hacking at a handful of other board scripts, and it'd probably just be better to apply that knowledge than to try to describe it.

Don't get me wrong, matsuba isn't nearly as bad as the average PHP script – it really is clean in a lot of places, but it has a lot of quirks. More of hard-to-maintain, and perhaps suffering from Second System Syndrome.

Example: the logic for how posts get deleted is split between the database and the filesystem, and neither of the two "talk" to each other. As it is, deleting a file causes a database request; that returns a list of referenced files and thread IDs that were affected by the request; the controller passes that information onto the filesystem handler, which actually does the deleting; then the controller gets back a list of files that were actually deleted, checks to see if one of those files was the same url where the request originated. (That's how you end up on the same page after deleting something – unless you deleted the thread from its own page.)

In a way, the current structure makes sense from a design perspective, but it makes things too complicated and doesn't provide much benefit. If I were redesigning things I'd just have one unified data store for everything; it'd simplify the code tremendously, which, of course, would make things more maintainable and better in the long run.

</soapbox>