The second one is by using two
different
apache modules. It *does not break anything*, but it's a pain to
setup.
Judging sheerly by functionality and compatibility the second ways is
better.
However, judging from what I know about PHP, nobody tries to make that
way easier, because everybody assume that everyone else use the first
way. Is it good old catch 22 in action, or are there some design
considerations I'm not aware of?
A great number of people have worked on, and are working on, ways to
make this easier.
Most people, however, find it more practical to simply have 2
different server configurations (old and new) and migrate clients onto
the new server slowly, at the CLIENT'S pace, instead of losing
customers by just trashing their site out from under them.
Actually, I was speaking about PHP developers. The sheer fact that they
bothered to write compatibility mode shows that they don't really count
on hosters using two engines side-by-side. On the other hand, the only
disadvantage of such approach is installation, and developers have the
power to remove this shortcoming. Since they preferred the first way of
handling compatibility, there must be some language design issues with
the second one. It would be interesting to know/discuss them.
--
Best regards,
Roman S.I.
http://sf.net/projects/naturalgine/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
