View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001738||Xdebug||Step Debugging||public||2020-01-23 14:25||2021-03-18 09:39|
|Summary||0001738: Ability to send text over stream.|
|Description||While attached to a php program with DBGp, I would like an option to stream arbitrary messages to the IDE over DBGp.|
Use case: Framework tracing information in IDE.
DBGp defines "stdout" and "stderr" stream. Currently, there is no way to use "stderr", for example, with "error_log" or similar.
Propose function xdebug_stream_write(stream, text) that would enable the user to send text over an arbitrary stream. This could be complemented with xdebug_stream_create(stream) or similar.
Optionally a streamWrapper could be create for something like:
$s = fopen("dbgp://stderr", "w");
|Tags||No tags attached.|
||PS: I'm willing to write a patch if this would be considered.|
I don't really see a reason why Xdebug could not have something for this, but I do not think that it should use the *stream* packet for this. The stream packet does not allow for arbitrary data formats, and is really only meant for stdout/stderr. The spec is currently vague on which other stream types are allowed (https://xdebug.org/docs/dbgp#stream has "stdout|stderr"). The stream packet would only be really useful for unstructured data in any case. What I think what instead should be used, is the "notify" functionality (https://xdebug.org/docs/dbgp#notifications and https://xdebug.org/docs/dbgp#notify). This allows for arbitrary XML children that can contain more structured data.
So I would suggest to add a `xdebug_notify()` method, where the first argument is the notification type (to be prefixed with "xdebug:" as notify's "name" element), the second argument the data (which could be send as base64 encoded data as TEXT data, with NULL allowed for none), and then optionally a third + fourth argument where the third is the name of the custom name space, and the fourth a string containing an XML element with the right custom data type. If you can come up with a different/better API, then I'm open for that as well. But the API/data packet MUST fit in the current DBGp protocol.
||Yes, notify would also be useful. However I still like the simple "line based text" approach of stream. I'm not sure if there is a way to hook into STDERR, but, do you think redirecting error_log to that stream? I would also guess that some IDEs could have the stream function already implemented, whereas the notify option would require a tight protocol integration between the php code and IDE...|
||Is this issue still relevant to you?|
Yes, I would still like to have this.
Whether it's stream or notify, I don't have a preference.
I'm going to need to implement both in VSC anyway. stream just makes a bit more sense in a line-by-line based content.
Would you like a patch?
||Yes, a patch would be great. I would still prefer a notification for this, and I would also like to pass the specification of this feature on to the PhpStorm . They often have good ideas. So I think it would be best to start there?|
Yes, that makes perfect sense. I probably won't be able to get to this for a couple of days. Perhaps we can start with telling them what the general idea behind this is:
A way for PHP to send application logs to IDE.
For example a PHP CMS could have application level tracing implemented and while debugging it would help the developer to also see those in the same IDE.
An example of that could be Visual Studio and .NET where the output window shows things logged via Trace class calls. In case of windows this is neither stdout or stderr but a special OS feature - I'm oversimplifying.
This could probably be solved with the existing DBGp stderr stream, but as far as I see this is not implemented due to technical limitations.
Proposed implementations are either <stream> or <notify> where in both cases we'd need to think about if the IDE should have an option to opt in and out of this specific data stream. We also need to think about other DBGp implementation (lua, python...).
I'm of course open to an alternative way to solve this feature, even if we can leverage something already in DBGp/Xdebug.
|2020-01-23 14:25||Zobo||New Issue|
|2020-01-23 14:28||Zobo||Note Added: 0005223|
|2020-01-27 20:32||derick||Assigned To||=> derick|
|2020-01-27 20:32||derick||Status||new => feedback|
|2020-01-27 20:32||derick||Note Added: 0005228|
|2020-02-03 11:55||Zobo||Note Added: 0005235|
|2020-02-03 11:55||Zobo||Status||feedback => assigned|
|2020-03-12 16:23||derick||Severity||minor => feature|
|2020-03-12 16:25||derick||Category||Feature/Change request => Remote Debugging|
|2020-03-12 16:33||derick||Category||Remote Debugging => Step Debugging|
|2021-03-17 09:30||derick||Status||assigned => feedback|
|2021-03-17 09:30||derick||Note Added: 0005752|
|2021-03-17 13:57||Zobo||Note Added: 0005788|
|2021-03-17 13:57||Zobo||Status||feedback => assigned|
|2021-03-17 17:29||derick||Note Added: 0005796|
|2021-03-18 09:39||Zobo||Note Added: 0005800|