 |
| Fig 1. The wrong end of a stick |
One chap done all the work required to make it compatible with PHP7, and wrote all the cool new stuff. That was Bob Weinand (@bwoebi).
Before I go further, thank you Bob.
One of these cool updates was the improvement of remote operation of phpdbg.
When phpdbg was merged, you could operate it remotely, but, it was what I referred to as protocol-free, that is to say that stdin and stdout were a socket pair, like an old inetd service. A quite horrible design in reality.
When phpdbg was merged, we had probably spent about a week writing it, it didn't have all problems solved, still doesn't.
We were only focused, for a very short time, on writing an interactive debugger, like gdb is to C.
We never intended to step on the toes of xdebug, xdebug is very mature software, a staple of the ecosystem today, and has been for many years. You would have to be barking mad to ignore that.
We had a quite narrow scope, there are things in the debugger clearly aimed at internals developers.
All we wanted was something like gdb for the Zend VM.
Debugging PHP at the engine level is not so easy, when you are trying to do things like write patches for Zend, introduce new opcodes, bend the rules in an extension somehow.
I think the second kind of break point we supported was an opline address, something almost completely unknown to most PHP programmers, impossible to discover in user land by normal means.
We need to be able to debug normal code too, so, based on a simplified set of gdb commands, we set about giving it the kind of features we need to debug code, as it happens the kind of features PHP programmers need too.
At this point, we thought we did have something quite cool, something useful for more than just internals developers. We showed it to a few people, who exhibited an interest in trying it. While that conversation was going on it was requested, by Andi Gutmans at Zend, that we RFC for inclusion and distribute phpdbg with PHP.
We were not aiming for that, we were happy to just write it, and get a tiny patch merged into php-src to make distribution outside of the php-src tree possible for Windows.
We were of course pretty pleased with ourselves, we done the RFC thing and it was voted in, unanimously.
So far, phpdbg has been included in two dot releases of PHP, most people probably haven't used it yet, it's still very young software.
Before any release of PHP included phpdbg, the users of PHPStorm started talking about integration, someone used their feature request system to request that the PHPStorm team at least investigate it.
You can guess their investigations showed that phpdbg wasn't really suitable for use in an IDE.
However, they started a productive conversation with us, they were keen on trying something new, and we are quite happy to put effort into making phpdbg more accessible.
At first, I said we should use dbgp, because maximum gain. However, I didn't do the work, I wasn't involved in the conversation with PHPStorm guys very much. It turns out that dbgp is just not suitable for our needs.
That's all we done, we haven't started any war.
We are still not stepping on the toes of xdebug, xdebug is still extremely mature software and people will continue to use it.
phpdbg is fundamentally different to xdebug, you cannot in all cases use phpdbg for the same things as xdebug.
phpdbg does some stuff that xdebug doesn't do, however, the number of people really needing those things are probably few.
You could say that there is some competition, because of overlap. Perfectly healthy competition, that we never really wanted to get into.
Whatever about it, there is no war.
We dropped the ball, and misunderstood the situation, which made internals noisy.
The title of the vote on the RFC is "Distribute phpdbg with PHP5.6+".
At no time until this weekend was it mentioned that we should need to go through the RFC process to develop our project.
This is not the understanding we actually had, and I'm not sure what we intend to do about it yet, or even if we can do anything.
