-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tim,

> I was hoping for some insight from a Six Apart employee.

Yes... but you've got one already, of course:
<http://groups.yahoo.com/group/mt-dev/message/574>.

Anyway, yes, we absolutely realize that there are downsides to
implementing dynamic pages in PHP. But there are also quite a few
upsides--Brad detailed those very well already, so I won't be
redundant.

Here's some rationale behind the various decisions made, and the
requirements we put on the feature:

* Movable Type needed a dynamic publishing system. This has been an
important issue to people for almost 3 years now (since MT's release),
and it's only becoming more important.

* The dynamic publishing system should be compatible with the maximum #
of templates possible *without requiring users to modify those
templates*. As released in 3.1, the PHP publishing system is compatible
with all of the tags in our default templates. It's not, as you well
know, compatible with tags implemented in plugins.

* Movable Type 3.1 had to be released. A couple of messages in this
thread have suggested that 3.1 was rushed, but it wasn't any more
rushed than any other software product--there are always tradeoffs,
there's always last-minute stuff, etc., as you all know. It was very
important to us that we release 3.1 quickly after the 3.0 developer
release, and if doing so meant that 3.1 did not support all of the tags
in MT's lexicon (or tags in existing plugins), that's a tradeoff we
felt was worth it.

* Dynamic publishing had to work, with the minimum amount of effort,
for the largest number of users possible.

* Dynamic publishing could not put so much load on a server that
Movable Type would be banned by hosting providers. :)

So, those were the basic criteria.

Tim, you've suggested that there are a number of other ways that we
could/should have implemented the feature, and I'd be very interested
in hearing those. Some of the other techniques we've thought about are:

1. Building a Perl-based dynamic viewer. In fact, this exists. It's
lib/MT/App/Viewer.pm, coupled with mt-view.cgi. It's been in there
since 2.6, and it's very experimental, and I will bet you that if you
run it as a CGI script, your host will shut you down, because frankly,
CGI is not a good interface for running applications that are going to
get hit over and over again.

Not acceptable: inefficient.

2. A perl-based dynamic viewer that would only run under mod_perl. This
is a subset of #1, of course, and it would be *fantastic* for the .01%
of MT users who run MT under mod_perl. :) That's a completely made-up
percentage, BTW, and the actual percentage is probably much lower.

Not acceptable: not widely available.

3. A variant of #1 that cached data in the filesystem. This is much
more efficient than #1, but CGI is still very inefficient, so in the
end, it's just not good enough. It's still something we're going to
keep testing, though, because it had the most promise.

Not acceptable: still inefficient.

4. A PHP viewer that executed Perl code as system calls. This has the
benefit of being in PHP but working with existing plugins, but the
downside of being, umm, even more inefficient than #1.

Not acceptable: inefficient.

5. Using PHP 5's support for executing Perl code
(<http://www.zend.com/php5/articles/php5-perl.php>). In the future,
this may be a great option, but it's not ready.

Not acceptable: not widely available, not stable.

I hope that helps. All of the above criteria pointed to PHP, because
it's widely available, fast, and a language that a lot of people know.
And we absolutely realize that plugins that add template tags require
some reimplementation--unfortunately, because of the criteria above, we
didn't see any way to make the dynamic publishing system compatible
with the existing plugins that add template tags.

A couple of things we plan to do to ease the task of adding PHP support
to plugins:

* We'll be writing tutorials on implementing plugins in PHP (there's
already some documentation in
<http://www.movabletype.org/docs/mtmanual_dynamic.html>, in fact).

* Currently, reimplementing a tag in PHP requires rewriting a lot of
code. We're working on coming up with mechanisms that would reduce that
amount of code quite a bit by allowing PHP plugins to make better use
of data generated by the Perl code, including data in the PluginData
table.

Tim also mentioned that developers should have been given a technology
preview, and he's correct--in fact, seeds were given to a small group
of developers, contest winners in particular, to ensure that. It's
regrettable that we didn't have the Professional Network instated
during the 3.1 development process, because that would have been a
perfect venue to vet a lot of these decisions and get early word out.
We did invite everyone who pre-registered for the ProNet to participate
in the beta process, but we want to make that a more organized process.

And make no mistake about it, that's what we plan to do with the
Professional Network: we want to give people advance notice of new
features (particularly features relevant to developers) and advance
developer seeds of the product.

So... this is a long message, but I hope it helps to give some
rationale behind the thinking that went into this feature. I know
you'll let me know what you think. :)

Ben

- --
Benjamin Trott, CTO, Six Apart
http://www.sixapart.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBNtXBzGeEk2uv818RAjfaAKCy8ORbENDC4706cYMcCjkvEXyMIgCgvPhj
SKFAIDryLEjcDz34ackgOzs=
=1KYc
-----END PGP SIGNATURE-----