Problems with incorporating markdown into a project

[John Gruber]

Lou Quillio <public at quillio.com> wrote on 05/08/05 at 8:00 am:

> Why not store the data as Markdown, transform it at display time,
> and be done?  It's not expensive.  That's what I have Drupal doing
> (at TextDrive) and it performs just fine.

Depends on your definition of expensive. If you're running on a
shared hosting account and hope to survive, say, a slashdotting, I
certainly wouldn't want to be running text through Markdown on every
single page view.

I could be wrong, but I don't think PHP Markdown could do
5,000-10,000 hits per hours, and if you're using the Perl version,
you almost certainly couldn't get away with firing up that many
instances of Markdown via CGI.

If I were designing my own CMS, I would definitely store each post
twice in the database -- raw Markdown for editing, and an XHTML
version that would more or less be used as a cache. In fact, maybe
instead of storing the XHTML transformed version in the database,
I'd store it in the file system and just `readfile()` it or
something with PHP.


> With all this transforming and de-transforming, something's bound to
> go wrong.  I just don't see the advantage.  If there were one, it'd
> be performance, and that seems easier to address by storing two
> representations.

I think html2text is excellent, but I'd never use it as part of a
round trip for CMS editing. You lose all your custom Markdown link
labels, for example. That's just the nature of the beast, not a
complaint.

-J.G.