Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51556
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=MkJ70rcPhgv0H7/stIMZ1snV4rMqK07J7wIjP90oBfC9SZvVJYwpzmCD2MuUTb9TP8
         Pm9Q5yUxOQRH3QivjGAgxmfCm+3/w37lFnMjdv3CGP6d1EDQYLtbwbzNYvkFcPuGjQtP
         utsLBMqbyglks5kPKJ1zRsvpJdEvqLy2Gjt0o=
Message-ID: <4D6F5C79.5070104@gmail.com>
Date: Thu, 03 Mar 2011 10:16:41 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Moriyoshi Koizumi <mozo@mozo.jp>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <AANLkTinAt4ToUv-FtOeSjbw4Db9iFitE7VvRNZF8yNAc@mail.gmail.com> <4D6ECD36.1070804@gmail.com> <AANLkTi=OW9EoTeqOO0vp3xO3YibZ5k4eP+am2B-TW7cz@mail.gmail.com>
In-Reply-To: <AANLkTi=OW9EoTeqOO0vp3xO3YibZ5k4eP+am2B-TW7cz@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: built-in web server in CLI.
From: keisial@gmail.com ("=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=")

Moriyoshi Koizumi wrote:
>> Regarding the patch (https://gist.github.com/835698):
>> I don't see a switch to disable the internal parse on configure.
> I don't see any obvious reason it should be able to be turned off
> through the build option.  The only problem is binary size increase,
> which I guess is quite subtle.
Seems sufficiently different from normal cli.

>> The patch looks messy as it splits main in two functions, so it gets
>> hard to follow,
>> but is probably good overall.
> Assuming you are mentioning about the option parsing portion of the
> code, yes, it's a bit messy, but I had to do so because runtime
> initialization procedure is very different from the ordinary CLI.
Wasn't critizising you. It's a limitation of unified diffs, which can't say
"move this bunch of code 25 lines down". A bit hard to follow, but
aparently good.


>> The change from php_printf to printf in line 3988 looks wrong.
> php_printf() eventually redirects the output to
> sapi_module.ub_write(), which should only be available after proper
> SAPI initialization.  The changed part can be reached before the
> initialization and it absolutely makes no sense to use php_printf()
> when you simply want to print a message text before the script starts
> in the console.
Fair enough.


>> Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ?
> cli-win32 version of PHP doesn't have an associated console and is
> supposed to use to create applications without console interactions
> (i.e. GUI).  So, It doesn't make sense to enable this feature for it.
With the embedded web server, the interaction would be done via the browser.