That just seems really fragile to me. Yank one space off the front of any article and the entire thing is jacked. I'm just not convinced that it's all that terrible to parse the markup on the way out if you need it transformed, while enforcing strict rules on what (valid) markup can go in.
I agree. The majority of their concerns can be addressed by parsing out markup on the way into the DB and storing the markup-free version in a separate location. This is a lot of acrobatics for marginal return.
I'm especially doubtful of it, because the article doesn't explain the problem with the obvious approach you suggested.
I feel bad to be so negative toward an idea I haven't fully explored, but I get the impression that the author of this article is trying hard to justify a bad approach rather than fixing the code.
Either way, you would have to parse it into something equivalent to what they are storing in the database so you you could handle the various target formats individually.
As long as you tightly control writes to the database, I don't see the problem. And, you don't have the overhead of parsing on every read. For an environment where reads will be a few orders of magnitude greater than writes, it does make some sense.
It seems incredible that they can't sacrifice some speed to parse on every read, and yet are also unwilling to sacrifice some disk space to cache several fully parsed versions.
Considering how quickly CPU and disk performance change, this type of tightrope-balanced optimization seems crazy. Or maybe they're way smarter than me.
