PHPDBG scope

Hi,

Why should phpdbg scope be limited, and not extended? As far as I know,
xdebug is nowhere like an official php project, so overlap shouldn't be an
issue.

I'm not saying phpdbg has to be extended, but I'm wondering why it should
be limited.

Regards,

Hi,

This is based on an email conversation between Joe Watkins and me. I
asked him
what the original scope of phpdbg was, and I've summarized his reply
here:

• PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
  like commands to debug, and step through code.
• Support for breaking on an opline, something that no userland PHP
  users would need.
• Support for breaking on lines, was an additional step later.
• For PHP programmers, which spend most of their time at the console.
• Not "intended to cover PHP's primary domain of HTTP requests".

Then later, they "documented a way that you could use it to emulate an
HTTP request, by setting those superglobals and executing your index.php

• your code doesn't know the difference between a real request, and a
  cli-like script with the same super globals set."

And Joe indicates, that with that addition, the "flood gates opened". He
also said that he "would still like to remain in that narrow scope,
phpdbg is still useful in it's current (pre xml stuff) form." and that
it was never meant to "usurp xdebug", as "that is not where we were
aiming, and it's an extremely unrealistic thing to even want."

And I very much agree that the above bullet points, is what phpdbg's
scope should be.

Joe, if I got this wrong, then please say so :-)

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

--

--
Florian Margaine

Am 03.11.2014 um 22:03 schrieb Derick Rethans derick@php.net:

Hi,

This is based on an email conversation between Joe Watkins and me. I
asked him
what the original scope of phpdbg was, and I've summarized his reply
here:

• PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
  like commands to debug, and step through code.
• Support for breaking on an opline, something that no userland PHP
  users would need.
• Support for breaking on lines, was an additional step later.
• For PHP programmers, which spend most of their time at the console.
• Not "intended to cover PHP's primary domain of HTTP requests“.

That was the initial purpose of phpdbg, correct. But now it has outgrown of itself, I think.
But also, to begin something, you need concrete goals. In this case that was nice tiny debugger for cli PHP users and devs. Very true.

Then later, they "documented a way that you could use it to emulate an
HTTP request, by setting those superglobals and executing your index.php

• your code doesn't know the difference between a real request, and a
  cli-like script with the same super globals set."

And Joe indicates, that with that addition, the "flood gates opened". He
also said that he "would still like to remain in that narrow scope,
phpdbg is still useful in it's current (pre xml stuff) form." and that
it was never meant to "usurp xdebug", as "that is not where we were
aiming, and it's an extremely unrealistic thing to even want.“

It wasn’t with that addition the "flood gates opened". This addition came alongside with the initial xml protocol development (though in a separate branch), because I thought, if users are going to debug web apps, they most likely will need that.

And true, we aren’t trying to usurp xdebug, it was planned to coexist. Nothing like competition, but it was asked that we make it debuggable by an IDE. The xml protocol stuff just was a consequence of that request, to make it possible.

And I very much agree that the above bullet points, is what phpdbg's
scope should be.

Also, why do we want an arbitrarily narrowed scope?

Joe, if I got this wrong, then please say so :-)

cheers,
Derick

Regards,
Bob

Hi,

Derick wrote:

I asked him what the original scope of phpdbg was,...
And I very much agree that the above bullet points,

The original scope of a project and what it should be in the future
are not related always related. Please don't pretend that they're the
same thing.

Derick wrote:

I've summarized his reply here:

Taking a private conversation and presenting it as what someone else
agrees to is also an underhand tactic.

From your emails to this list, you plainly wish to limit what PHPDBG
does. You may even have valid reasons for those wishes, but please
stop using underhand tactics to limit what other people are trying to
do.

cheers
Dan

Hi,

This is based on an email conversation between Joe Watkins and me. I
asked him
what the original scope of phpdbg was, and I've summarized his reply
here:

• PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
  like commands to debug, and step through code.
• Support for breaking on an opline, something that no userland PHP
  users would need.
• Support for breaking on lines, was an additional step later.
• For PHP programmers, which spend most of their time at the console.
• Not "intended to cover PHP's primary domain of HTTP requests".

Then later, they "documented a way that you could use it to emulate an
HTTP request, by setting those superglobals and executing your index.php

• your code doesn't know the difference between a real request, and a
  cli-like script with the same super globals set."

And Joe indicates, that with that addition, the "flood gates opened". He
also said that he "would still like to remain in that narrow scope,
phpdbg is still useful in it's current (pre xml stuff) form." and that
it was never meant to "usurp xdebug", as "that is not where we were
aiming, and it's an extremely unrealistic thing to even want."

And I very much agree that the above bullet points, is what phpdbg's
scope should be.

Joe, if I got this wrong, then please say so :-)

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

Hi!

• PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
  like commands to debug, and step through code.

That was also my impression when the RFC was discussed.
Now, I do not object in principle on growing the scope of phpdbg. But
this needs to be done the right way if it's the php.net core part -
having an RFC that explains what exactly happens and why, getting
consensus, and only then merging.

Then later, they "documented a way that you could use it to emulate an
HTTP request, by setting those superglobals and executing your index.php

• your code doesn't know the difference between a real request, and a
  cli-like script with the same super globals set."

I don't think this as such is a bad idea, I wouldn't mind having such
thing available, I can see use cases where it would be handy.

So I think it would be useful to have some ordered RFC describing where
phpdbg wants to expand to and then we can discuss it and see if we can
arrive at something that would be ok with everybody.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

Hi,

This is based on an email conversation between Joe Watkins and me. I
asked him
what the original scope of phpdbg was, and I've summarized his reply
here:

• PHPDBG was originally envisioned as a "gdb" for the Zend VM, with gdb
  like commands to debug, and step through code.
• Support for breaking on an opline, something that no userland PHP
  users would need.
• Support for breaking on lines, was an additional step later.
• For PHP programmers, which spend most of their time at the console.
• Not "intended to cover PHP's primary domain of HTTP requests".

Then later, they "documented a way that you could use it to emulate an
HTTP request, by setting those superglobals and executing your index.php

• your code doesn't know the difference between a real request, and a
  cli-like script with the same super globals set."

And Joe indicates, that with that addition, the "flood gates opened". He
also said that he "would still like to remain in that narrow scope,
phpdbg is still useful in it's current (pre xml stuff) form." and that
it was never meant to "usurp xdebug", as "that is not where we were
aiming, and it's an extremely unrealistic thing to even want."

And I very much agree that the above bullet points, is what phpdbg's
scope should be.

Joe, if I got this wrong, then please say so :-)

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

--

Morning Internals,

Thank you Derick.

    "Why should phpdbg scope be limited, and not extended?"

It's not about limiting the scope of phpdbg, it's about defining it

properly.

The right tool for the job is what we are talking about.

phpdbg will *never* be able to do all the things xdebug can do, and it

would ruin it to try.

In the same way, there are things phpdbg can do that would further

complicate xdebug (or even be impossible), and we shouldn't try that
either, obviously.

"The original scope of a project and what it should be in the future

are not always related"

True, but in this case it does actually matter. 

You will never be able to load phpdbg in any SAPI and debug any web

request in a robust way. It was never intended for that, it is limited,
in that sense, because it's a SAPI.

Being a SAPI allows us to do things you cannot do in an extension, such

as overriding Zend's memory management routines. We have features based
on these abilities.

I very much agree that we should keep phpdbg within the scope it was

designed for.

I'm not saying we should not extend the features of phpdbg, but, we

should do it knowing what it actually is, knowing that it is
fundamentally different to xdebug.

Cheers
Joe