2011/3/3 Ángel González <keis...@gmail.com>:
> Moriyoshi Koizumi wrote:
>> Hi,
>>
>> Just to let you know that I wrote a RFC about built-in web server
>> feature with which PHP can serve contents without a help of web
>> servers. That would be handy for development purpose.
>>
>> If interested, have a look at http://wiki.php.net/rfc/builtinwebserver .
>>
>> Regards,
>> Moriyoshi
> I like the idea.
>
> 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.
> I'd expect the files to be on its own folder inside sapi, even being
> able to
> bundle them in a single binary.
>
> Why is this needed on WIndows?
>
> + ADD_FLAG("LIBS_CLI", "ws2_32.lib");
>
> Surely php will already link with the sockets library for its own functions.
Of course the objects that directly involves generation of php.exe
depend on WinSock functions. Other socket related portion is inside
php5.dll (php5ts.dll) whose imported symbols cannot be referred to
unlike ELF shared objects.
> The http parser code seems copied from https://github.com/ry/http-parser and
> it may not be a good idea to modify it downstream, but it seems to do more
> things than strictly needed by php (eg. there are more methods than those a
> php server would take use).
> It also seems to be a hand-coded lexer, so that's much more verbose than a
> set of rules.
Do we really have to look into the parser right now? I don't think we
have to limit the methods that the server can accept since there is no
reason limiting it though the server can deal with, I don't find it a
problem for it to be hand-coded either.
> 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.
> 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.
> 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.
Regards,
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
