On Sep 2, 2004, at 4:11 AM, Benjamin Trott wrote:

> 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. :)

Thank you Ben. It does help. I think a lot and will try and be as
concise as possible. (This message will be long anyway, but it could
have been much much longer.)

I want to repeat my stance one more time for all just so that is
abundantly clear: options are good, very good. The need for dynamic
page generation understandable. PHP is fine too. Its how this feature
is implemented and was introduced that I have issue with.

One of the biggest burdens I find to working with MT these days is that
it requires A LOT of effort to figure out how things work and what is
in there because of a lack of timely and accurate documentation.

I did receive the technology preview and frankly didn't notice it was
in there until someone mentioned it matter-of-factly at BlogOn. I take
the responsibility for not having done my part and looked at those
previews so I could said something sooner. I didn't have the time
(still don't) in the short span from preview release to beta and didn't
realize I was looking at such a seismic shift in architecture. (I had
to create (guess at?) my own change log by diffing the lib directory in
the the "sneak peaks" and post it to the mailing list.) In hindsight
though Six Apart should have made it more of an issue in its
communication. It also should have eased something this big into the
community. Having handed out the documentation to how the dynamic page
generation system works under the hood and how plugins are developed
would have been marvelous!

The options you explored were mostly what I was thinking with option 3
being the most promising also though I had more in mind.

As mentioned by Ben Hammersley, I would have put more effort into the
optimizing the rebuild functionality. Part and parcel to that, I would
have explored how templates are developed and constructed so they could
be optimized for static AND dynamic generation. The bonus being those
opting to stick with static generation also benefit. In my experience
working with users complaining about the rebuild time of MT, a fair
amount was due to resource intensive elements being used repetitively
throughout their templates primarily in their sidebars and navigation
-- next/previous X, latest entry/comments and calendars being the
biggest culprits.

For some time now I've had the concept of a "Master Site Template" on
my wishlist. (Start at around the 4th paragraph of this post for what I
mean: http://www.timaoutloud.org/archives/000311.html) While making
users lives easier by avoiding all of the cutting and pasting involved
in the current system, I would think this could help performance
because that HTML would be generated once and could be cached or used
in the dynamic assembly pages whether it be PHP or Perl.

I also know the comments in the rebuild process says that "There is not
a good way to determine exact dependencies", but could a template be
tokenized and its tag usage recorded when its saved so rebuilds like
next/previous pages are more intelligent? (If my templates don't have a
NextEntry tag why rebuild the next entry?) Couldn't some of this more
intensive information be cached for faster lookups? What if MT would
rebuild a series of HTML fragments and assemble those with a
lightweight CGI (ala blosxom perhaps with a bit of funky caching)
instead of going through the whole MT startup and initialization and
incurring the overhead?

I would have been OK with some type of special tag set or other
delineation for dynamic page generation. (By making it seem as easy as
checking a box, you give an impression that isn't consistent with
reality -- if you use plugins the templates won't work.) A tool to
convert existing templates (instead of the check box) to dynamic ones
and flag issues (unrecognized tags) along with advise to potentially
working around them -- like Arvind's advise of includes -- would have
been brilliant. While this flies in the face of some of the ideals Ben
laid out, so does the current implementation. I've seen a number of
users grumbling that their templates don't work. Yes its because their
layouts use plugin tags, but as we know, users don't read the manual --
some may not even know which tags are plugins and which are not. This
is why the current approach and its introduction is so serious in my
mind.

The current solution essentially says that the users ideals are
absolute and the weight of these ideals will be dumped on (3rd party)
developers and there are no tradeoffs. Developers must work twice as
hard and be equally as proficient in two languages in order to meet
user expectations. I know this was probably not the intent, but that is
the result in its current state.

The dynamic page generation technology should have been released as a
separate entity and once plugins, know-how and design issues were
worked out, integrating it into the MT core. If any thing warranted the
"D" moniker in MT this is it!

I realize figuring this out is not trivial (then again that's why you
folks are making the big bucks!) and that my ideas are admittedly half
baked since I don't have the resources or motivation to figure them
out. Despite the analysis you shared, I'm sorry to say that this was
still hastily rushed to market and more care should have been applied
by easing this into the community rather then the big bang it is.

Now the toothpaste is out of the tube and I'm dreading the impact it
going to have my projects and the tool that I've bet my current career
and livelihood on.

I regret if I come off heavy handed or a whining crotchety old man (I
have not plans of and a donation of $500 to WordPress), but this is how
I honestly feel and it serves little purpose in my mind to not state
it.

<tim/>
---
Timothy Appnel
http://www.timaoutloud.org/