Become a Patron!

My Amazon wishlist can be found here.

Life Line

Debugging Protocol Shoot-out (Part 2)

Guy Harpaz posted a reply to my Debugger Protocol Shoot-out on his newly created blog. In this post he tries to counter some of my arguments. I don't quite understand why he couldn't just have posted his comments here though. (And in case why you're wondering why I'm not adding a comment to his post: You need a account to comment, and I refuse to create one just to be able to comment on a blog).

The first thing that strikes me as odd is the following quote:

We chose performance (binary based protocol) over easy
server side implementation (textual based protocol).

Easy implementation was never the reason for going with a textual based protocol. The main reason was to allow extensions to the protocol be as easy as possible. Cramming as much data in as little bytes as possible is also not going to increase performance if your protocol has no ways to paginate through arrays with many elements or when you have no means of limiting the amount of data in one variable to be send over the wire. This is very useful incase you have a few MB files in variables for example.

The second argument why you should "choose Zend Studio's protocol" is:

DBGp supports several scripting languages and from this
derives some of its disadvantages. We believe that a debug protocol
should be as 'close' as possible to the PHP language.

This doesn't make much sense to me, as far as I know Eclipse is a multi language IDE. Secondly, which disadvantages there are is not mentioned.

Then Guy tries to compare some security points:

The Proxy mechanism has few bugs in it

If that is the case, would you mind telling us where?

He further mentions:

The PHP IDE debug protocol does not specify requirements for
a security system but defines that the Debug server should receive the
client IP before initializing the session. By using the IP,
implementing a security mechanism is very simple.

Xdebug doesn't specify any requirements either. Xdebug could implement an extra security that checks whether the IP is allowed to be used as debugging IDE client. However, when you are on a NAT-ted local network, and your dev server is somewhere outside of this network you have a problem without a proxy. As there is no way for the debugging engine on the developer machine to connect to individual IDEs anymore (as the IPs are simply not accessible by the devel server because of NAT). The proxy-server based approach of DBGp allows your devel server to connect to the proxy on one IP and one port (which also means you have to poke only one hole in your firewall). The IDE then simply have to make itself known to the proxy server with its "idekey" to allow debugging through a NAT-ted network.

The last point that Guy raises is:

DBGp supports PHP execution stdout and stderr as a general
solution for all supported languages. PHP IDE as a specific protocol
for PHP can distingue between header output and standard output and
between all types of PHP errors (warnings, errors and

It really has nothing to do whether a protocol is specifically made for PHP or not to allow the sending of HTTP headers. DBGp currently has no options for sending headers, but that would not be hard to add. It definitely would not be the selling point on why somebody should "choose Zend Studio's protocol".


This article has a short URL available:


Ok, binary is shorter/more bandwidth efficient and that's obvious to anymone.

This being said, we are talking about debugging, right ? What would be the benefit of a more efficient protocol ? Being able to have 10'000 simultaneous debug sessions on a single server with a binary protocol instead of only 5'000 with a text one ?

In my mind, debugging is done by an handful of people simultaneously on a developement server that is likely to be in the same LAN and with a CPU load of 0.0. The amount of byte sent and received is simply irrelevant.

Beside, I've heard about a few protocols, like html, xhtml, xml, soap, ajax and the al. Last time I checked, they were rather full text protocols, isn't it ? ;)

I've only used xdebug on a LAN, is this really using a lot of bandwidth ?


Would it be possible to compress this textual data? and likewise decompress it on the IDE side, wouldn't this make this "textual" data probably as fast as the binary protocol?

@Ammar: sure we can... but it is really not a problem to have it as textual strings in the first place, so why bother?

I'm definietely with you derick, from technical side and from the "spirit of open source site".

Zend, or Mr. Harpaz in this case, just doesn't carry the spirit of open source, interchangability and heterogeneousity. Your point about Eclipse being multiplatform about just anything is well placed.

@derick: Ofcourse it is no real problem, but this would end the "Binary protocol is faster" debate. Which I find really silly( From Zend's point of view ). But still having this feature in the future releases might be worth it for people debugging remote servers on a slow connection.

Add Comment


Will not be posted. Please leave empty instead of filling in garbage though!

Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.

All comments are moderated