Thanks Hartmut, that added some much needed clarity. One comment I have to offer is the clutter you mention strongly suggests a refactoring was needed to lift from common code the CLI or CGI affected code.
Including or omitting entire modules appropriate for each environment is also a pretty good argument for seperating the two variants. As Leon has suggested, why not just compile the variants into different directories? Say add a "cli/" (since the CLI is newer). Only one directory would go into the PATH (presumably). In the case of the Win32 variant, it looks like distinct DLLs (if using a PHP DLL) might be a good idea. -----Original Message----- From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 8:44 AM Shane Caraveo wrote: > It would have been simple enough to combine > cli into the cgi binary and be done with it, and I suggested as much > that it should be done a very long time ago. > I don't recall any major > reasons why it wasn't done, other than that cli has been experimental. Way back CGI and CLI *did* share one binary (the CGI binary) and the code was cluttered with code behaviour depending on the environment the binary was called in. The code with all these situation-dependant if() blocks was a true mess getting even worse with every new CGI- or CLI-only feature added. Even worse: some features and extensions don't make sense in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other features belong into a CGI binary only. The introduction of the seperate CLI binary or SAPI happened for two reasons: - removal of situation-dependant code in the CGI thus cleaning up the code base(as stated above) - the ability to build the CLI alongside with *every* SAPI So we can argue about binary naming, but definetly *not* about about the CGI/CLI split. No matter how similar the two binaries might look, they *aren't* -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
