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
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 .
I like it. Need to go through it very carefully and look for
security-related issues though. Make sure all memory handling is safe.
-Rasmus
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 .
I like it. Need to go through it very carefully and look for
security-related issues though. Make sure all memory handling is safe.
Same here, very handy. I would not worry too much about security
related issues as such builtin server should really be used for
development purposes only (yes, users do bad things even if we say to
do not it :).
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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'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.
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.
The patch looks messy as it splits main in two functions, so it gets
hard to follow,
but is probably good overall.
The change from php_printf to printf in line 3988 looks wrong.
Any special reason to disable it on PHP_CLI_WIN32_NO_CONSOLE ?
2011/3/3 Ángel González keisial@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
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.
Hi,
2011/3/3 Ángel González keisial@gmail.com:
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.
I've seen a number of people arguing on the same, but I'd rather have
them both in for the sake of simplicity. As discussed when the CLI
version of PHP was born, multiple PHP binaries actually have confused
the users to a certain degree.
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.
I would have put a whitespace-ignoring diff as well ;-)
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.
It is not intended to be daemonized at all since it's just a
development web server. To do more, Apache should work great then.
Regards,
Moriyoshi
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 .
Interesting, indeed.
I noticed, that you hardcode mimetypes and index_files.
Mimetypes can probably be obtained from the system — we even had some
extension doing that.
And index_files should be configurable, because there are some
situations when people don't want any mime-types at all.
Also, it would be good to be able to configure which files are
actually parsed by php, not just served. Currently, these are only
".php" files
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
Hi,
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 .
Interesting, indeed.
I noticed, that you hardcode mimetypes and index_files.
Mimetypes can probably be obtained from the system — we even had some
extension doing that.
And index_files should be configurable, because there are some
situations when people don't want any mime-types at all.Also, it would be good to be able to configure which files are
actually parsed by php, not just served. Currently, these are only
".php" files
We coundn't always count on the existence of mime.types, which is
likely installed with Apache that is uncalled for. Neither do I see
any good reason to make index files configurable because I have hardly
seen such a peculiar setting for several years that uses file names
other than index.html or index.php for index files. I used to use
index.htm for technical reasons though.
In short, if you need to configure it more, it'd be better off
installing Apache to do the right job. I would like to cover just a
marginal part of the developer needs with this.
Regards,
Moriyoshi
--
Alexey Zakhlestin, http://twitter.com/jimi_dini
http://www.milkfarmsoft.com/
In short, if you need to configure it more, it'd be better off
installing Apache to do the right job. I would like to cover just a
marginal part of the developer needs with this.
I like it being small and simple as well. Sometimes "forcing" people to
use one method actually makes things easier to use.
cheers,
Derick
Derick Rethans wrote:
In short, if you need to configure it more, it'd be better off
installing Apache to do the right job. I would like to cover just a
marginal part of the developer needs with this.
I like it being small and simple as well. Sometimes "forcing" people to
use one method actually makes things easier to use.
AND a lot easier to debug when people are having problems getting something
working ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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
To allow for future changes, all options should require flags.
For example, php -S localhost:8000 -d docroot instead of the
currently proposed php -S localhost:8000 docroot
Have you thought about integration with run-tests.php?
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
On Fri, Mar 4, 2011 at 11:17 AM, Christopher Jones
christopher.jones@oracle.com 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,
MoriyoshiTo allow for future changes, all options should require flags.
For example, php -S localhost:8000 -d docroot instead of the
currently proposed php -S localhost:8000 docroot
That might make sense. I am thinking that being unable to specify a
document root with a router script is a bit inconsistent.
Have you thought about integration with run-tests.php?
Not in mind yet, but if it's better than CGI.
Moriyoshi
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet.
Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
Regards,
Philip
As a non core dev, I would like to say that the patches are so handy
and this feature will be so helpful in portable php development
scenarios.
+1 on this and hoping it will make into the main branch pretty soon.
Similar with others, my suggestion is to put the docroot and router
script as parts of the options. An option to specify max number of
connections would be nice but perhaps it can be in a future wishlist.
Regards,
Mike
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet.
Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698Regards,
Philip
As a non core dev, I would like to say that the patches are so handy
and this feature will be so helpful in portable php development
scenarios.
+1 on this and hoping it will make into the main branch pretty soon.Similar with others, my suggestion is to put the docroot and router
script as parts of the options. An option to specify max number of
connections would be nice but perhaps it can be in a future wishlist.Regards,
MikeGreetings Moriyoshi and all,
Are people still thinking about this? And how about applying the current/revised patch to trunk thus making it easier to play with and break, but not freeze its features/API yet.
Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698Regards,
Philip
What would happen if you could combine these patches with the
Win32Service pecl extension ... could you not have a real PHP
orientated web server running which was capable of starting up and
shutting down with the OS.
Hey! Who would need IIS or Apache then! (OK. Just kidding).
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
I really like the idea.
Just to be clear though I'd change:
Server is listening on localhost:8000... Press CTRL-C to quit.
To something like:
PHP Development Server is listening on localhost:8000... Press CTRL-C to quit.
I think that makes it very clear this is for development and enhancements will be focused on ensuring the dev environment works and not trying to make this into a mini Apache.
Andi
-----Original Message-----
From: Richard Quadling [mailto:rquadling@gmail.com]
Sent: Sunday, April 17, 2011 1:29 PM
To: Mikael Fernandus S
Cc: Philip Olson; Moriyoshi Koizumi; Christopher Jones; internals Mailing List
Subject: Re: [PHP-DEV] RFC: built-in web server in CLI.As a non core dev, I would like to say that the patches are so handy
and this feature will be so helpful in portable php development
scenarios.
+1 on this and hoping it will make into the main branch pretty soon.Similar with others, my suggestion is to put the docroot and router
script as parts of the options. An option to specify max number of
connections would be nice but perhaps it can be in a future wishlist.Regards,
MikeGreetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and break, but
not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698Regards,
PhilipWhat would happen if you could combine these patches with the Win32Service
pecl extension ... could you not have a real PHP orientated web server running
which was capable of starting up and shutting down with the OS.Hey! Who would need IIS or Apache then! (OK. Just kidding).
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY--
To unsubscribe, visit:
http://www.php.net/unsub.php
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and
break, but not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
The php_http_* "namespace" is actually already used by pecl_http?
Regards,
Mike
Since the goal of this is debugging might I suggest borrowing a statement
from the Adobe Flash environment: trace.
Trace sends output to the debug console. If given a variable it would
format it as print_r currently does. When encountered by PHP in other modes
it would be silently ignored.
Thoughts?
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and
break, but not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
The php_http_* "namespace" is actually already used by pecl_http?
Regards,
Mike
Pardon me for following up my own post, but there is room for a range of
functions here other than trace that could send their output to the command
line where the server was started.
watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then each
time it changes it is updated in the console.
traceStack() -> as trace, but the current stack is reported.
traceAll() Return all variables in local scope and the current stack.
stop() Halt execution as die or exit, unlike them it's arguments are sent to
console instead of browser.
On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris dmgx.michael@gmail.comwrote:
Since the goal of this is debugging might I suggest borrowing a statement
from the Adobe Flash environment: trace.Trace sends output to the debug console. If given a variable it would
format it as print_r currently does. When encountered by PHP in other modes
it would be silently ignored.Thoughts?
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and
break, but not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
The php_http_* "namespace" is actually already used by pecl_http?
Regards,
Mike
I'm not sure if this is needed when there are already solutions for this.
eg, syslog, error_log, or other userland solutions like Zend_Log,
sfLogger, etc.
Cheers,
David
Pardon me for following up my own post, but there is room for a range of
functions here other than trace that could send their output to the command
line where the server was started.watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then each
time it changes it is updated in the console.traceStack() -> as trace, but the current stack is reported.
traceAll() Return all variables in local scope and the current stack.
stop() Halt execution as die or exit, unlike them it's arguments are sent to
console instead of browser.On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris dmgx.michael@gmail.comwrote:
Since the goal of this is debugging might I suggest borrowing a statement
from the Adobe Flash environment: trace.Trace sends output to the debug console. If given a variable it would
format it as print_r currently does. When encountered by PHP in other modes
it would be silently ignored.Thoughts?
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and
break, but not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
The php_http_* "namespace" is actually already used by pecl_http?
Regards,
Mike
Those userland solutions (I've written a few myself) send the output as part
of the html file that is being composed, or they write it to a file which
you then later open up. Which is fine.
This takes advantage of the fact that this CLI client, which will not be
running as a daemon, will have an open terminal window for it for as long as
it persists until the process is stopped with CTRL-C. Sending output to
that terminal window would be very useful in my opinion, hence the call
for trace. Essentially, trace is "echo" to that terminal window, or
"print_r" to that window if it is given an object or array.
The userland solutions you mention can later be enhanced to take advantage
of this trace function when they are running in the CLI webserver
environment if their authors so choose.
So can this be done now? Yes and no - Yes in the sense that, with a little
creative working around, we can get the debug data. No in that the proposed
trace statement has two key properties the userland solutions do not and
CANNOT have:
- It sends to the CLI webserver terminal if one exists.
- If one does not exist the statement is discarded like comment text.
I'm not sure if this is needed when there are already solutions for this.
eg, syslog, error_log, or other userland solutions like Zend_Log,
sfLogger, etc.Cheers,
DavidPardon me for following up my own post, but there is room for a range of
functions here other than trace that could send their output to the
command
line where the server was started.watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then
each
time it changes it is updated in the console.traceStack() -> as trace, but the current stack is reported.
traceAll() Return all variables in local scope and the current stack.
stop() Halt execution as die or exit, unlike them it's arguments are sent
to
console instead of browser.On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris <dmgx.michael@gmail.com
wrote:Since the goal of this is debugging might I suggest borrowing a
statement
from the Adobe Flash environment: trace.Trace sends output to the debug console. If given a variable it would
format it as print_r currently does. When encountered by PHP in other
modes
it would be silently ignored.Thoughts?
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and
break, but not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
The php_http_* "namespace" is actually already used by pecl_http?
Regards,
Mike
This takes advantage of the fact that this CLI client, which willnot be
running as a daemon, will have an open terminal window for it for as long as
it persists until the process is stopped with CTRL-C. Sending output to
that terminal window would bevery useful in my opinion, hence the call
for trace. Essentially, trace is "echo" to that terminal window, or
"print_r" to that window if it is given an object or array.
error_log() output should go there by default. (didn't check the patch)
you can route everything there. I don't think it's good to add tons of
extra functions for that.
johannes
This takes advantage of the fact that this CLI client, which
willnot be
running as a daemon, will have an open terminal window for it for as
long as
it persists until the process is stopped with CTRL-C. Sending output to
that terminal window would bevery useful in my opinion, hence the call
for trace. Essentially, trace is "echo" to that terminal window, or
"print_r" to that window if it is given an object or array.
error_log()output should go there by default. (didn't check the patch)
you can route everything there. I don't think it's good to add tons of
extra functions for that.
I think the difference with the trace() approach is that it could be a
NOOP by default, and just print to console when running the php httpd,
so you could theoretically leave debug output in, and I will leave
everyone the liberty to interpret that as a good or bad idea.
Cheers
--
Jordi Boggiano
@seldaek :: http://seld.be/
--e0cb4e43cce199248e04a15872c6
Content-Type: text/plain; charset=ISO-8859-1Those userland solutions (I've written a few myself) send the output
as part of the html file that is being composed, or they write it to a
file which you then later open up. Which is fine.This takes advantage of the fact that this CLI client, which will
not be running as a daemon, will have an open terminal window for it
for as long as it persists until the process is stopped with CTRL-C.
Sending output to that terminal window would be very useful in my
opinion, hence the call for trace. Essentially, trace is "echo" to
that terminal window, or "print_r" to that window if it is given an
object or array.
I'm going to correct one of your assumptions here, which is "or they
write it to a file."
Zend_Log has an adapter-based approach to log writers. How the writer
performs its task is up to the developer. We have writers that write to
web services and databases. Our "file" writer is actually labelled
"Stream", because it uses streams.
This means you can use "php://stdout" to write to.
Additionally, you can have many writers attached to the logger. So, you
could have one writing to a file, and another to STDOUT.
This is all configurable via a factory.
And ZF's solution isn't unique; I've seen other logging solutions that
do similarly. My point is: don't dismiss userland solutions out-of-hand;
they may offer flexibility that a language-based solution cannot
provide.
The userland solutions you mention can later be enhanced to take
advantage of this trace function when they are running in the CLI
webserver environment if their authors so choose.So can this be done now? Yes and no - Yes in the sense that, with a
little creative working around, we can get the debug data. No in that
the proposed trace statement has two key properties the userland
solutions do not and CANNOT have:
- It sends to the CLI webserver terminal if one exists.
- If one does not exist the statement is discarded like comment text.
As I noted above, you can open a stream to php://stdout. If it's
unavailable, the text is basically discarded.
I'm not sure if this is needed when there are already solutions for this.
eg, syslog, error_log, or other userland solutions like Zend_Log,
sfLogger, etc.Cheers,
DavidPardon me for following up my own post, but there is room for a range of
functions here other than trace that could send their output to the
command
line where the server was started.watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then
each
time it changes it is updated in the console.traceStack() -> as trace, but the current stack is reported.
traceAll() Return all variables in local scope and the current stack.
stop() Halt execution as die or exit, unlike them it's arguments are sent
to
console instead of browser.On Tue, Apr 19, 2011 at 10:35 AM, Michael Morris <dmgx.michael@gmail.com
wrote:Since the goal of this is debugging might I suggest borrowing a
statement
from the Adobe Flash environment: trace.Trace sends output to the debug console. If given a variable it would
format it as print_r currently does. When encountered by PHP in other
modes
it would be silently ignored.Thoughts?
Greetings Moriyoshi and all,
Are people still thinking about this? And how about applying the
current/revised patch to trunk thus making it easier to play with and
break, but not freeze its features/API yet.Also the wiki is up again so:
- RFC: https://wiki.php.net/rfc/builtinwebserver
- Patch is here: http://gist.github.com/835698
The php_http_* "namespace" is actually already used by pecl_http?
Regards,
Mike--
--
--e0cb4e43cce199248e04a15872c6--
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then each
time it changes it is updated in the console.
Just my 0.02 as a user, but it strikes me that watch() could be a handy
addition that would be difficult and/or extremely painful to do in userland.
Dave
watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then each
time it changes it is updated in the console.
Just my 0.02 as a user, but it strikes me that watch() could be a handy
addition that would be difficult and/or extremely painful to do in userland.
... but this can be relatively easily be done in a debug extension and
that's where this belongs.
johannes
2011/4/20 Johannes Schlüter johannes@schlueters.de:
watch ($var) -> $var is sent to the console on the line this statement
is
made with the statment "now watching 'var'.. init value "x", and then
each
time it changes it is updated in the console.Just my 0.02 as a user, but it strikes me that watch() could be a handy
addition that would be difficult and/or extremely painful to do in
userland.... but this can be relatively easily be done in a debug extension and
that's where this belongs.johannes
If the extension could allow for userland interpretation of the debug
events ... then I think that's the best of all worlds.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
watch ($var) -> $var is sent to the console on the line this statement is
made with the statment "now watching 'var'.. init value "x", and then each
time it changes it is updated in the console.
Just my 0.02 as a user, but it strikes me that watch() could be a handy
addition that would be difficult and/or extremely painful to do in userland.Dave
Being able to watch($var [, ...]), unwatch($var [, ...]) and
trace([bool $start = true]) without a debugger in userland ...
Just like you can overload session handling logic by using
session_set_save_handler(), would something like ...
bool debugging_set_handler(callback $watch, callback $unwatch, callback $trace);
be of use?
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY