Re: CGI and CLI

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. 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. Zeev At 14:14 19/12/2002, Marcus Börger wrote:

At 20:59 18.12.2002, Andrei Zmievski wrote:

What 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

After reading through the whole thread i came to the conclusion that there are two 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