At 13:23 19.12.2002, Zeev Suraski wrote:
I think you forgot to take one fact into account - PHP 4.2.x already had CLI/CGI binaries, both having the same name. Keeping 4.3 with the 4.2 behavior, and then merging the modules back in 4.3.1 is the best solution as far as I can tell. Merging the modules does not have serious compatibility-breaking drawbacks, and either way, these drawbacks, if any, will be identical whether they happen in 4.3 or 4.3.1.As i said: If merging then merging in 4.3.0. I do not see any reason not to make
such changes in 4.3.0 besides the time of 4.3.0 release.
About 'BC at all costs', I'm a big advocate of BC, but describing this issue as 'BC at all costs' is just plain wrong. The cost here is tiny, it's a tiny price to pay for BC and simplicity.I used the phrase "BC at all costs" to over emphasize the following: Having any name
Zeev
other than php is really bad for CLI.
You are right to say the cost is tiny if the solution is merging. But i am for instance
strongly against that.
I forgot to recall one more thing: CLI is EXPERIMENTAL in 4.2.x so keeping CLI as
in 4.2.x is the least important thing in this whole issue.
At 14:14 19/12/2002, Marcus Börger wrote:At 20:59 18.12.2002, Andrei Zmievski wrote:After reading through the whole thread i came to the conclusion that there are twoWhat was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear.-Andrei
parties. The first wants BC for all costs and the second wants improovements. The
improovement party started the whole issue.
They wanted to overcome the necessary workarounds that allows CGI being used as
a shell utility (mostly with shebang lines like with perl). To accomplish this the best
way seemed to have a new executable handling this correctly (and different than CGI).
This required the new executable CLI being called php to have it beeing a replacement.
At this point it that was not considered being a problem for two reasons. First CGI has
to be installed anyway and second noone thought about windows problems at that
time. So far the history as i see/remeber it.
Then the problem on windows was reported and the BC party got alarmed claimed that
new things have to have new names and all BC has to be kept. (point)
From my point of view having CLI with a different name than php does not make much
sense but it is far more better than merging the two. Merging would make the code
allmost unreadable and would also slow down the code (where are those saying speed
is everything?). And of cause merging is against the idea that we will have different
behaviour from different executables for different tasks. (And edin already showed an
example where merging will leed to errors).
And now to the ideas mentioned from several people here:
a) Merging CLI & CGI read above.
b) Merging in 4.3.1 seems the worst thing we can do. It contradicts nearly all thoughts
we have heared here just to have 4.3.0 out asap. But more important it leeds to one
more different behaving version. And most important it contradicts one rule: Only bug
fixes in such releases.
c) --install-cli[=dir] + --install-cgi[=dir]: Nice idea but we do not have a real problem under
*nix. The problem is in windows. However i like the idea but think that having defaults
for them is necessary (For me that would be --install-cli={$prefix]/bin and CGI to something
differnet).
d) keeping CGI and CLI in their sapi directories before installation is a good idea. It would
make handling easier and clearer. If there is no php in ./ i know what php i get when
fetching it from a sapi directory.
e) having both using the name php will confuse the users way to much. And we would
reach the opposite of what started the issue: less bugreports and questions.
f) Throwing an error or notice when missusing one of the two seems a good idea to me
as long as this message can be disabled (See example shown by edin). And i do not see
any problem with that. In fact that would be the best solution to introduce such changes
because notes and hints in documents or readmes are being ignored by to many users.
g) Calling CGI from CLI when CLI is used as CGI seems a good idea as long as it can be
disabled at first sight. But it makes things more complicated and e) is the better way.
h) None of the above solves the problem under windows: But i do not get it: Even on
windows an executable can be called with its full path. So there is only a little change
that has do be done on all platforms when renaming CGI executable to php-cgi: Only
one configure line has to be changed. And those users being to lazy to read installation
docs, news and change logs can be given hints by e).
i) We are late in release process.
After all this points we have to question ourselves: Do we want php becoming a widely
accepted command line utility (which it is already for many users) even when this will
cost use to mark some bug reports bogus or documentation problems? Isn't it a fact
that sometimes evolution requires changes?
Just to make my conclusion clear: I favor CGI with the new name php-cgi + c) d) e)
since BC is not everything.
marcus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
