5.1 Standard DBGP port

The IDE listens on port 9000 for debugger connections, unless the IDE is using a proxy, in which case it may listen on any port. In that case, the IDE will tell the proxy which port it is listening on, and the proxy should listen on port 9000. While this document defines port 9000 as the standard DBGP port, an implementation may support the use of any port. Current implementations accept various forms of configuration that allow this port to be defined.

5.2 Connection Initialization

When a debugger engine connects to either a IDE or proxy, it must send an init packet:

<init appid="APPID"
      idekey="IDE_KEY"
      session="DBGP_COOKIE"
      thread="THREAD_ID"
      parent="PARENT_APPID"
      language="LANGUAGE_NAME"
      protocol_version="1.0"
      fileuri="file://path/to/file">

Attributes in the init element can include:

Attribute	Description
appid	defined by the debugger engine
idekey	defined by the user. The DBGP_IDEKEY environment variable SHOULD be used if it is available, otherwise setting this value is debugger engine implementation specific. This value may be empty.
session	If the environment variable DBGP_COOKIE exists, then the init packet MUST contain a session attribute with the value of the variable. This allows an IDE to execute a debugger engine, and maintain some state information between the execution and the protocol connection. This value should not be expected to be set in 'remote' debugging situations where the IDE is not in control of the process.
thread_id	the systems thread id
parent_appid	the appid of the application that spawned the process. When an application is executed, it should set it's APPID into the environment. If an APPID already exists, it should first read that value and use it as the PARENT_APPID.
language_name	debugger engine specific, must not contain additional information, such as version, etc.
protocol	The highest version of this protocol supported
fileuri	URI of the script file being debugged

The IDE responds by dropping socket connection, or starting with debugger commands.

The init packet may have child elements for additional vendor specific data. These are entirely optional and must not effect behavior of the debugger interaction. Suggested child elements include:

<engine version="1.abcd">product title</engine>
<author>author</author>
<company>company</company>
<license>licensing info</license>
<url>url</url>
<copyright>xxx</copyright>

5.3 Just in time debugging and debugger proxies

Proxies are supported to allow multiuser systems work with a defined port for debugging. Each IDE would listen on a unique port and notify the proxy what port it is listening on, along with a key value that is used by the debugger engine to specify which IDE it should be connected with.

With the exception of the init packet, all communications will be passed through without modifications. A proxy could also implement support for just in time debugging. In this case, a debugger engine would break (perhaps on an error or exception) and connect to the proxy. The proxy would then start the IDE (if it is not already running) and initiate a debugging session with it.

The method for handling just in time debugging is not defined by the protocol and is implementation specific. One example of how this may work is that the proxy has a configuration file that defines key's for each user, along with the path to the executable that will provide the UI for that user. The debugger engine would have to know this key value in advance and provide it to the proxy in the init packet (see IDE_KEY in section 5.2). The proxy would know if the IDE is running, since the IDE should have communicated with the proxy already, if it has not, the proxy could execute the IDE directly.

To support proxies and jit deamons, the IDE should be configured with and ip:port pointing to the proxy/jit. The IDE then makes a connection to the proxy when it starts and sends the following command:

IDE command

proxyinit -a ip:port -k ide_key -m [0|1]

-p	the port that the IDE listens for debugging on. The address is retrieved from the connection information.
-k	a IDE key, which the debugger engine will also use in it's debugging init command. this allows the proxy to match request to IDE. Typically the user will provide the session key as a configuration item.
-m	this tells the demon that the IDE supports (or doesn't) multiple debugger sessions. if -m is missing, zero or no support is default.

IDE command

proxystop -k ide_key

The IDE sends a proxystop command when it wants the proxy server to stop listening for it.

The proxy should respond with a simple XML statement alerting the IDE to an error, or the success of the initialization (see section 6.5 for more details on the error element).

<proxyinit success="[0|1]"
           idekey="{ID}">
    <error id="app_specific_error_code">
        <message>UI Usable Message</message>
    </error>
</proxyinit>

Once the IDE has sent this command, and received a confirmation, it disconnects from the proxy. The IDE will only connect to the proxy when it initially wants to start accepting connections from the proxy, or when it wants to stop accepting connections from the proxy.

5.4 Multiple Processes or Threads

The debugger protocol is designed to use a separate socket connection for each process or thread. The IDE may or may not support multiple debugger sessions. If it does not, the debugger engine must not attempt to start debug sessions for threads, and the IDE should not accept more than one socket connection for debugging. The IDE should tell the debugger engine whether it supports multiple debugger sessions, the debugger engine should assume that the IDE does not. The IDE can use the feature_set command with the feature name of 'multiple_sessions' to notify the debugger engine that it supports multiple session debugging. The IDE may also query the the debugger engine specifically for multithreaded debugging support by using the feature_get command with a feature name of 'language_supports_threads'.

5.5 Feature Negotiation

Although the IDE may at any time during the debugging session send feature_get or feature_set commands, the IDE should be designed to negotiate the base set of features up front. Differing languages and debugger engines may operate in many ways, and the IDE should be prepared to handle these differences. Likewise, the IDE may dictate certain features or capabilities be supported by the debugger engine. In any case, the IDE should strive to work with all debugger engines that support this protocol. Therefore, this section describes a minimal set of features the debugger engine must support. These required features are outlined here in the form of discussion, actual implementation of feature arguments are detailed in section 7 under the feature_get and feature_set commands.

6.1 Why not XML both ways?

The primary reason is to avoid the requirement that a debugger engine has an XML parser available. XML is easy to generate, but requires additional libraries for parsing.

6.2 Packet Communications

The IDE sends a command, then waits for a response from the debugger engine. If the command is not received in a reasonable time (implementation dependent) it may assume the debugger engine has entered a non-responsive state. The exception to this is when the IDE sends a 'continuation' command which may not have an immediate response.

'continuation' commands include, but may not be limited to: run, step_into, step_over, step_out and eval. When the debugger engine receives such a command, it is considered to have entered a 'run state'.

During a 'continuation' command, the IDE should expect to possibly receive stdin and/or stderr packets from the debugger engine prior to receiving a response to the command itself. It may also possibly receive error packets from either the debugger engine, or a proxy if one is in use, either prior to the 'continuation' response, or in response to any other command.

Stdout and stderr, if requested by the IDE, may only be sent during commands that have put the debugger engine into a 'run' state.

If the debugger engine supports asynchronous commands, the IDE may also send commands while the debugger engine is in a 'run' state. These commands should be limited to commands such as the 'break' or 'status' commands for performance reasons, but this protocol does not impose such limitations. The debugger engine MUST respond to these commands prior to responding to the original 'run' command.

An example of communication between IDE and debugger engines. (this is not an example of the actual protocol.)

IDE:  feature_get supports_async
DBG:  yes
IDE:  stdin redirect
DBG:  ok
IDE:  stderr redirect
DBG:  ok
IDE:  run
DBG:  stdin data...
DBG:  stdin data...
DBG:  reached breakpoint, done running
IDE:  give me some variables
DBG:  ok, here they are
IDE:  evaluate this expression
DBG:  stderr data...
DBG:  ok, done
IDE:  run
IDE:  break
DBG:  ok, breaking
DBG:  at breakpoint, done running
IDE:  stop
DBG:  good bye

6.3 IDE to debugger engine communications

A debugging IDE (IDE) sends commands to the debugger engine in the form of command line arguments. One argument that is included in all commands is the data length. The data itself is the last part of the command line. The data may be binary data if the encoding argument is 'binary'.

command [SPACE] [arguments] [SPACE] base64(data) [NULL]

Standard arguments for all commands

-i      Transaction ID
        unique for each command generated by the IDE

6.4 debugger engine to IDE communications

The debugger engine always replies or sends XML data. The standard namespace for the root elements returned from the debugger engine MUST be "urn:debugger_protocol_v1". Namespaces have been left out in the examples in this document. The messages sent by the debugger engine must always be NULL terminated. The XML document tag must always be present to provide XML version and encoding information.

Two base tags are used for the root tags:

data_length
[NULL]
<?xml version="1.0" encoding="UTF-8"?>
<response command="command_name"
          transaction_id="transaction_id"/>
[NULL]

data_length
[NULL]
<?xml version="1.0" encoding="UTF-8"?>
<stream type="stdout|stderr">...Base64 Data...</stream>
[NULL]

For simplification, data length and NULL bytes will be left out of the rest of the examples in this document.

6.5 debugger engine errors

A debugger engine may need to relay error information back to the IDE in response to any command. The debugger engine may add an error element as a child of the response element. Note that this is not the same as getting language error messages, such as exception data. This is specifically a debugger engine error in response to a IDE command. IDEs and debugger engines may elect to support additional child elements in the error element, but should namespace the elements to avoid conflicts with other implementations.

<response command="command_name"
          transaction_id="transaction_id">
    <error code="error_code" apperr="app_specific_error_code">
        <message>UI Usable Message</message>
    </error>
</response>

6.5.1 Error Codes

The following are predefined error codes for the response to commands:

000 Command parsing errors

0 - no error
1 - parse error in command
2 - duplicate arguments in command
3 - invalid options (ie, missing a required option)
4 - Unimplemented command
5 - Command not available (Is used for async commands. For instance
    if the engine is in state "run" than only "break" and "status"
    are available). 

100 File related errors

100 - can not open file (as a reply to a "source" command if the
      requested source file can't be opened)
101 - stream redirect failed 

200 Breakpoint, or code flow errors

200 - breakpoint could not be set (for some reason the breakpoint
      could not be set due to problems registering it)
201 - breakpoint type not supported (for example I don't support
      'watch' yet and thus return this error)
202 - invalid breakpoint (the IDE tried to set a breakpoint on a
      line that does not exist in the file (ie "line 0" or lines
      past the end of the file)
203 - no code on breakpoint line (the IDE tried to set a breakpoint
      on a line which does not have any executable code. The
      debugger engine is NOT required to return this type if it
      is impossible to determine if there is code on a given
      location. (For example, in the PHP debugger backend this
      will only be returned in some special cases where the current
      scope falls into the scope of the breakpoint to be set)).
204 - Invalid breakpoint state (using an unsupported breakpoint state
      was attempted)
205 - No such breakpoint (used in breakpoint_get etc. to show that
      there is no breakpoint with the given ID)
206 - Error evaluating code (use from eval() (or perhaps
      property_get for a full name get))
207 - Invalid expression (the expression used for a non-eval()
      was invalid) 

300 Data errors

300 - Can not get property (when the requested property to get did
      not exist, this is NOT used for an existing but uninitialized
      property, which just gets the type "uninitialised" (See:
      PreferredTypeNames)).
301 - Stack depth invalid (the -d stack depth parameter did not
      exist (ie, there were less stack elements than the number
      requested) or the parameter was < 0)
302 - Context invalid (an non existing context was requested) 

900 Protocol errors

900 - Encoding not supported
998 - An internal exception in the debugger occurred
999 - Unknown error 

6.6 file paths

All file paths passed between the IDE and debugger engine must be in the URI format specified by IETF RFC 1738 and 2396, and must be absolute paths.

6.7 Dynamic code and virtual files

The protocol reserves the URI scheme 'dbgp' for all virtual files generated and maintained by language engines. Such virtual files are usually managed by a language engine for dynamic code blocks, i.e. code created at runtime, without an association with a regular file. Any IDE seeing an URI with the 'dbgp' scheme has to use the 'source' command (See section 7.14) to obtain the contents of the file from the engine responsible for that URI.

All URIs in that scheme have the form:

dbgp:engine-specific-identifier

The engine-specific-identifier is some string which the debugger engine uses to keep track of the specific virtual file. The IDE must return the URI to the debugger engine unchanged through the source command to retrieve the virtual file.

7.1 status

The status command is a simple way for the IDE to find out from the debugger engine whether execution may be continued or not. no body is required on request. If async support has been negotiated using feature_get/set the status command may be sent while the debugger engine is in a 'run state'.

The status attribute values of the response may be:

starting:

State prior to execution of any code

stopping:

State after completion of code execution. This typically happens at the end of code execution, allowing the IDE to further interact with the debugger engine (for example, to collect performance data, or use other extended commands).

stopped:

IDE is detached from process, no further interaction is possible.

running:

code is currently executing. Note that this state would only be seen with async support turned on, otherwise the typical state during IDE/debugger interaction would be 'break'

break:

code execution is paused, for whatever reason (see below), and the IDE/debugger can pass information back and forth.

The reason attribute value may be:

• ok
• error
• aborted
• exception

IDE

status -i transaction_id

debugger engine

<response command="status"
          status="starting"
          reason="ok"
          transaction_id="transaction_id">
    message data
</response>

7.2 Options and Configuration

The feature commands are used to request feature support from the debugger engine. This includes configuration options, some of which may be changed via feature_set, the ability to discover support for implemented commands, and to discover values for various features, such as the language version or name.

An example of usage would be to send a feature request with the string 'stdin' to find out if the engine supports redirection of the stdin stream through the debugger socket. The debugger engine must consider all commands as keys for this command, but may also have keys that are for features that do not map directly to commands.

breakpoint_set
break
eval

feature-get -i transaction_id -n feature_name

<response command="feature_get"
          feature_name="feature_name"
          supported="0|1"
          transaction_id="transaction_id">
    feature setting or available options, such as a list of
    supported encodings
</response>

feature_set -i transaction_id -n feature-name -v value

<response command="feature_set"
          feature="feature_name"
          success="0|1"
          transaction_id="transaction_id"/>

7.5 continuation commands

resume the execution of the application.

run:

starts or resumes the script until a new breakpoint is reached, or the end of the script is reached.

step_into:

steps to the next statement, if there is a function call involved it will break on the first statement in that function

step_over:

steps to the next statement, if there is a function call on the line from which the step_over is issued then the debugger engine will stop at the statement after the function call in the same scope as from where the command was issued

step_out:

steps out of the current scope and breaks on the statement after returning from the current function. (Also called 'finish' in GDB)

stop:

ends execution of the script immediately, the debugger engine may not respond, though if possible should be designed to do so. The script will be terminated right away and be followed by a disconnection of the network connection from the IDE (and debugger engine if required in multi request apache processes).

detach (optional):

stops interaction with the debugger engine. Once this command is executed, the IDE will no longer be able to communicate with the debugger engine. This does not end execution of the script as does the stop command above, but rather detaches from debugging. Support of this continuation command is optional, and the IDE should verify support for it via the feature_get command. If the IDE has created stdin/stdout/stderr pipes for execution of the script (eg. an interactive shell or other console to catch script output), it should keep those open and usable by the process until the process has terminated normally.

The response to a continue command is a status response (see status above). The debugger engine does not send this response immediately, but rather when it reaches a breakpoint, or ends execution for any other reason.

IDE

run -i transaction_id

debugger engine

<response command="run"
          status="starting"
          reason="ok"
          transaction_id="transaction_id"/>

7.6 breakpoints

Breakpoints are locations or conditions at which a debugger engine pauses execution, responds to the IDE, and waits for further commands from the IDE. A failure in any breakpoint commands results in an error defined in section 6.5.

The following DBGP commands relate to breakpoints:

breakpoint_set	Set a new breakpoint on the session.
breakpoint_get	Get breakpoint info for the given breakpoint id.
breakpoint_update	Update one or more attributes of a breakpoint.
breakpoint_remove	Remove the given breakpoint on the session.
breakpoint_list	Get a list of all of the session's breakpoints.

There are six different breakpoints types:

Type	Req'd Attrs	Description
line	filename, lineno	break on the given lineno in the given file
call	function	break on entry into new stack for function name
return	function	break on exit from stack for function name
exception	exception	break on exception of the given name
conditional	expression	break when the given expression is true at the given filename and line number or just in given filename
watch	expression	break on write of the variable or address defined by the expression argument

A breakpoint has the following attributes. Note that some attributes are only applicable for some breakpoint types.

type	breakpoint type (see table above for valid types)
filename	The file the breakpoint is effective in. This must be a "file://" URI.
lineno	Line number on which breakpoint is effective. Line numbers are 1-based. If an implementation requires a numeric value to indicate that lineno is not set, it is suggested that -1 be used, although this is not enforced.
state	Current state of the breakpoint. This must be one of enabled, disabled.
function	Function name for call or return type breakpoints.
temporary	Flag to define if breakpoint is temporary. A temporary breakpoint is one that is deleted after its first use. This is useful for features like "Run to Cursor". Once the debugger engine uses a temporary breakpoint, it should automatically remove the breakpoint from it's list of valid breakpoints.
hit_count	Number of effective hits for the breakpoint in the current session. This value is maintained by the debugger engine (a.k.a. DBGP client). A breakpoint's hit count should be increment whenever it is considered to break execution (i.e. whenever debugging comes to this line). If the breakpoint is disabled then the hit count should NOT be incremented.
hit_value	A numeric value used together with the hit_condition to determine if the breakpoint should pause execution or be skipped.
hit_condition	A string indicating a condition to use to compare hit_count and hit_value. The following values are legal: >= break if hit_count is greater than or equal to hit_value [default] == break if hit_count is equal to hit_value % break if hit_count is a multiple of hit_value
exception	Exception name for exception type breakpoints.

Breakpoints should be maintained in the debugger engine at an application level, not the thread level. Debugger engines that support thread debugging MUST provide breakpoint id's that are global for the application, and must use all breakpoints for all threads where applicable.

As for any other commands, if there is error the debugger engine should return an error response as described in section 6.5.

breakpoint_set -i TRANSACTION_ID [<arguments...>] -- base64(expression)

breakpoint_set -i 1 -f test.pl -l 20 -- base64($x > 3)

<response command="breakpoint_set"
          transaction_id="TRANSACTION_ID"
          state="STATE"
          id="BREAKPOINT_ID"/>

breakpoint_get -i TRANSACTION_ID -d BREAKPOINT_ID 

<response command="breakpoint_get"
          transaction_id="TRANSACTION_ID">
    <breakpoint id="BREAKPOINT_ID"
                type="TYPE"
                state="STATE"
                filename="FILENAME"
                lineno="LINENO"
                function="FUNCTION"
                exception="EXCEPTION"
                hit_value="HIT_VALUE"
                hit_condition="HIT_CONDITION"
                hit_count="HIT_COUNT">
        <expression>EXPRESSION</expression>
    </breakpoint>
</response>

breakpoint_update -i TRANSACTION_ID -d BREAKPOINT_ID [<arguments...>]

<response command="breakpoint_update"
          transaction_id="TRANSACTION_ID"/>

breakpoint_remove -i TRANSACTION_ID -d BREAKPOINT_ID

<response command="breakpoint_remove"
          transaction_id="TRANSACTION_ID"/>

breakpoint_list -i TRANSACTION_ID

<response command="breakpoint_list"
          transaction_id="TRANSACTION_ID">
    <breakpoint id="BREAKPOINT_ID"
                type="TYPE"
                state="STATE"
                filename="FILENAME"
                lineno="LINENO"
                function="FUNCTION"
                exception="EXCEPTION"
                hit_value="HIT_VALUE"
                hit_condition="HIT_CONDITION"
                hit_count="HIT_COUNT">
        <expression>EXPRESSION</expression>
    </breakpoint>
    <breakpoint ...>...</breakpoint>
    ...
</response>

7.7 stack_depth

IDE

stack-depth -i transaction_id

debugger engine

<response command="stack_depth"
          depth="{NUM}"
          transaction_id="transaction_id"/>

7.8 stack_get

Returns stack information for a given stack depth. For extended debuggers, multiple file/line's may be returned by having child elements of the stack element. This is to allow for debuggers, such as XSLT, that have execution and data files. The filename returned should always be the local file system path translated into a file URI, and should include the system name if the engine is not connecting to an ip on the local box: file://systemname/c|/path. If the stack depth is specified, only one stack element is returned, for the depth requested, though child elements may be returned also. The current context is stack depth of zero, the 'oldest' context (in some languages known as 'main') is the highest numbered context.

-d	stack depth (optional)

IDE

stack_get -d {NUM} -i transaction_id

debugger engine

<response command="stack_get"
          transaction_id="transaction_id">
    <stack level="{NUM}"
           type="file|eval|?"
           filename="..."
           lineno="{NUM}"
           where=""
           cmdbegin="line_number:offset"
           cmdend="line_number:offset"/>
    <stack level="{NUM}"
           type="file|eval|?"
           filename="..."
           lineno="{NUM}">
        <input level="{NUM}"
               type="file|eval|?"
               filename="..."
               lineno="{NUM}"/>
    </stack>
</response>

Attributes for the stack element can include:

Attribute	Description
level	stack depth for this stack element
type	the type of stack frame. Valid values are file or eval.
filename	file URI
lineno	1-based line offset into the buffer
where	current command name (optional)
cmdbegin	line number and text offset from beginning of line for the current instruction (optional)
cmdend	same as cmdbegin, denotes end of current instruction

The attributes where, cmdbegin and cmdlength are primarily used for relaying visual information in the IDE. cmdbegin and cmdend can be used by the IDE for high lighting the command that is currently being debugged. The where attribute contains the name of the current stack. This could be the current function name that the user is stepping through.

7.9 context_names

The names of currently available contexts at a given stack depth, typically Local, Global and Class. These SHOULD be UI friendly names. The id attribute returned with the names is used in other commands such as context_get to identify the context. The context id zero is always considered to be the 'default' context is no context id is provided. In most languages, this will the be 'local' context.

-d	stack depth (optional)

IDE

context_names -d {NUM} -i transaction_id

debugger engine

<response command="context_names"
          transaction_id="transaction_id">
    <context name="Local" id="0"/>
    <context name="Global" id="1"/>
    <context name="Class" id="2"/>
</response>

7.10 context_get

Returns an array of properties in a given context at a given stack depth. If the stack depth is omitted, the current stack depth is used. If the context name is omitted, the context with an id zero is used (generally the 'locals' context).

-d	stack depth (optional)
-c	context id (optional, retrieved by context-names)

IDE

context_get -d {NUM} -i transaction_id

debugger engine

<response command="context_get"
          context="context_id"
          transaction_id="transaction_id">
    <property ... />
</response>

7.11 Properties, variables and values

Properties that have children may return an arbitrary depth of children, as defaulted by the debugger engine. A maximum depth may be defined by the IDE using the feature_set command with the max_depth argument. The IDE may then use the fullname attribute of a property to dig further into the tree. Data types are defined further in section 7.12 below.

The number of children sent is defined by the debugger engine unless otherwise defined by sending the feature_set command with the max_children argument.

<property
    name="short_name"
    fullname="long_name"
    type="data_type"
    classname="name_of_object_class"
    constant="0|1"
    children="0|1"
    size="{NUM}"
    page="{NUM}"
    pagesize="{NUM}"
    address="{NUM}"
    key="language_dependent_key"
    encoding="base64|none"
    numchildren="{NUM}">
...encoded Value Data...
</property>

Attributes in the property element can include:

Attribute	Description
name	variable name. This is the short part of the name. For instance, in PHP: $v = 0; // short name 'v' class:$v; // short name 'v'
fullname	variable name. This is the long form of the name which can be eval'd by the language to retrieve the value of the variable. $v = 0; // long name 'v' class::$v; // short name 'v', long 'class::$v' $this->v; // short name 'v', long '$this->v'
classname	If the type is an object or resource, then the debugger engine MAY specify the class name This is an optional attribute.
page	if not all the children in the first level are returned, then the page attribute, in combination with the pagesize attribute will define where in the array or object these children should be located.
pagesize	the size of each page of data, defaulted by the debugger engine, or negotiated with feature_set and max_children
type	language specific data type name
facet	provides a hint to the IDE about additional facets of this value. These are space separated names, such as private, protected, public, constant, etc.
size	size of property data in bytes
children	true/false whether the property has children this would be true for objects or array's.
numchildren	optional attribute with number of children for the property.
key	language dependent reference for the property. if the key is available, the IDE SHOULD use it to retrieve further data for the property
address	containing physical memory address
encoding	if this is binary data, it should be base64 encoded with this attribute set

7.12 Data Types

Languages may have different names or meanings for data types, however the IDE may want to be able to handle similar data types as the same type. For this reason, we define a minimal set of standard data types, and a method for specifying more explicit facets on those types. We provide three different type attributes, and a command to map those types to each other. The schema type serves as a hint to the IDE as to how to handle this specific data type, if it so chooses to, but should not be considered to be generally supported. If the debugger engine chooses to support Schema, it should handle all data validation itself.

language type:

A language specific name for a data type

common type:

A name used by the IDE to group data types that are similar or the same

schema type:

The XML Schema data type name as specified in the W3C Recommendation, XML Schema Part 2: Datatypes located at http://www.w3.org/TR/xmlschema-2/ The use of the schema type is completely optional. The language engine should not expect an IDE to support usage of this attribute. The IDE identifies support for this in the debugger engine by retrieving the data map, which would contain the schema type attribute.

typemap_get -i transaction_id

<response command="typemap_get"
          transaction_id="transaction_id"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <map type="common_type"
        name="language_type_name"
        xsi:type="xsd:schema_type_name"/>
</response>

<map type="float"
     name="float"
     xsi:type="xsd:float"/>
<map type="float"
     name="double"
     xsi:type="xsd:double"/>
<map type="float"
     name="real"
     xsi:type="xsd:decimal"/>

<response command="typemap_get"
          transaction_id="transaction_id"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
          xmlns:mytypes="http://mysite/myschema.xsd">
   <map type="resource"
        name="SpecialDataType"
        xsi:type="mytypes:SpecialDataType"/>
</response>

7.13 property_get, property_set, property_value

Gets/sets a property value. When retrieving a property with the get method, the maximum data that should be returned is a default defined by the debugger engine unless it has been negotiated using feature_set with max_data. If the size of the properties data is larger than that, the debugger engine only returns the configured amount, and the IDE should call property_value to get the entire data. This is to prevent large data from slowing down debugger sessions. The IDE should implement UI that allows the user to decide whether they want to retrieve all the data. The IDE should not read more data than the length defined in the packet header. The IDE can determine if there is more data by using the property data length information. As per the context_get command, the depth of nested elements returned is either defaulted by the debugger engine, or negotiated using feature_set with max_children.

-d	stack depth (optional, debugger engine should assume zero if not provided)
-c	context id (optional, retrieved by context-names, debugger engine should assume zero if not provided)
-n	property long name (required)
-m	max data size to retrieve (optional)
-t	data type (optional)
-p	data page (optional, for arrays, hashes, objects, etc.)
-k	property key as retrieved in a property element, optional, used for property_get of children and property_value, required if it was provided by the debugger engine.
-a	property address as retrieved in a property element, optional, used for property_set/value, required if it was provided by the debugger engine.

IDE

property_get -n property_long_name -d {NUM} -i transaction_id

debugger engine

<response command="property_get"
          transaction_id="transaction_id">
    <property ... />
    ...
</response>

IDE

property_set -n property_long_name -d {NUM} -i transaction_id
         -l data_length -- {DATA}

debugger engine

<response command="property_set"
      success="0|1"
      transaction_id="transaction_id"/>

IDE

property_value -n property_long_name -d {NUM} -i transaction_id

debugger engine

<response command="property_value"
          size="{NUM}"
          encoding="base64|none"
          transaction_id="transaction_id">
    ...data...
</response>

7.14 source

The body of the request is the URI (retrieved from the stack info), the body of the response is the data contents of the URI. If the file uri is not provided, then the file for the current context is returned.

-b	begin line (optional)
-e	end line (optional)
-f	file URI

IDE

source -i transaction_id -f fileURI

debugger engine

<response command="source"
          success="0|1"
          transaction_id="transaction_id">
    ...data source code...
</response>

7.15 stdout, stderr

Body of the request is null, body of the response is true or false. Upon receiving one of these redirect requests, the debugger engine will start to copy data bound for one of these streams to the IDE, using the message packets.

-c	[0|1|2] 0 - disable, 1 - copy data, 2 - redirection 0 (disable) stdout/stderr output goes to regular place, but not to IDE 1 (copy) stdout/stderr output goes to both regular destination and IDE 2 (redirect) stdout/stderr output goes to IDE only.

IDE

stdout -i transaction_id -c 1

debugger engine

<response command="stdout"
          success="0|1"
          transaction_id="transaction_id"/>

8.1 stdin

The stdin command has nearly the same arguments and responses as stdout and stderr from the core commands (section 7). Since redirecting stdin may be very difficult to support in some languages, it is provided as an optional command. Uses for this command would primarily be for remote console operations.

If an IDE wishes to redirect stdin, or cancel the stdin redirection, then it must send the stdin command with the -c argument, without any data. After the IDE has redirected stdin, it can send more stdin commands with the data. Sending both the -c argument and data in the same command is invalid.

If the IDE requests stdin, it will always be a redirection, and the debugger engine must not accept stdin from any other source. The debugger engine may choose to not allow stdin to be redirected in certain situations (such as when running under a web server).

-c	[0|1] 0 - disable, 1 - redirection 0 (disable) stdin is read from the regular place 1 (redirect) stdin is read from stdin packets received from the IDE.

IDE

stdin -i transaction_id -c 1
stdin -i transaction_id -- base64(data)

debugger engine

<response command="stdin"
          success="0|1"
          transaction_id="transaction_id"/>

8.2 break

This command can be sent to interrupt the execution of the debugger engine while it is in a 'run state'.

IDE

break -i transaction_id

debugger engine

<response command="break"
          success="0|1"
          transaction_id="transaction_id"/>

8.3 eval

Evaluate a given string within the current execution context. A property element MAY be returned as a child element of the response, but the IDE MUST NOT expect one. The string being evaluated may be an expression or a code segment to be executed. Languages, such as Python, which have separate statements for these, will need to handle both appropriately. For implementations that need to be more explicit, use the expr or exec commands below.

IDE

eval -i transaction_id -- {DATA}

debugger engine

<response command="eval"
      success="0|1"
      transaction_id="transaction_id">
      <property .../>
</response>

8.4 spawnpoints

Spawnpoints are points in (currently Tcl) file where a new debug session might (i.e. if this position is a point in the code where a new application is created) get spawned when hit. Spawnpoints are treated much like a different type of breakpoint: They share many of the same attributes as breakpoints, using a type=="spawn" to distinguish themselves. Spawnpoints have an equivalent set of commands. A failure in any spawnpoint commands results in an error defined in section 6.5.

The following DBGP commands relate to spawnpoints:

spawnpoint_set	Set a new spawnpoint on the session.
spawnpoint_get	Get spawnpoint info for the given spawnpoint id.
spawnpoint_update	Update one or more attributes of a spawnpoint.
spawnpoint_remove	Remove the given spawnpoint on the session.
spawnpoint_list	Get a list of all of the session's spawnpoints.

A spawnpoint has the following attributes:

type	always set to "spawn"
filename	The file the spawnpoint is effective in. This must be a "file://" URI.
lineno	Line number on which spawnpoint is effective. Line numbers are 1-based. If an implementation requires a numeric value to indicate that lineno is not set, it is suggested that -1 be used, although this is not enforced.
state	Current state of the spawnpoint. This must be one of enabled, disabled.

Spawnpoints should be maintained in the debugger engine at an application level, not the thread level. Debugger engines that support thread debugging MUST provide spawnpoint id's that are global for the application, and must use all spawnpoints for all threads where applicable.

As for any other commands, if there is error the debugger engine should return an error response as described in section 6.5.

spawnpoint_set -i TRANSACTION_ID [<arguments...>]

<response command="spawnpoint_set"
          transaction_id="TRANSACTION_ID"
          state="STATE"
          id="SPAWNPOINT_ID"/>

spawnpoint_get -i TRANSACTION_ID -d SPAWNPOINT_ID 

<response command="spawnpoint_get"
          transaction_id="TRANSACTION_ID">
    <spawnpoint id="SPAWNPOINT_ID"
                state="STATE"
                filename="FILENAME"
                lineno="LINENO"/>
</response>

spawnpoint_update -i TRANSACTION_ID -d SPAWNPOINT_ID [<arguments...>]

<response command="spawnpoint_update"
          transaction_id="TRANSACTION_ID"/>

spawnpoint_remove -i TRANSACTION_ID -d SPAWNPOINT_ID

<response command="spawnpoint_remove"
          transaction_id="TRANSACTION_ID"/>

spawnpoint_list -i TRANSACTION_ID

<response command="spawnpoint_list"
          transaction_id="TRANSACTION_ID">
    <spawnpoint id="SPAWNPOINT_ID"
                state="STATE"
                filename="FILENAME"
                lineno="LINENO"/>
    <spawnpoint .../>
    ...
</response>

8.5 Notifications

At times it may be desirable to recieve a notification from the debugger engine for various events. This notification tag allows for some simple data to be passed from the debugger engine to the IDE. Customized implementations may add child elements for additional data.

As an example, this is usefull for handling STDIN. The debugger engine interupts all STDIN reads, and when a read is done by the application, it sends a notification to the IDE. The IDE is then able to do something to let the user know the application is waiting for input, such as placing a cursor in the debugger output window.

A new feature name is introduced: notify_ok. The IDE will call feature_set with the notify_ok name and a TRUE value. This lets the debugger engine know that it can send notifications to the IDE. If the IDE has not set this value, or sets it to FALSE, then the debugger engine MUST NOT send notifications to the IDE.

The debugger engine MUST NOT expect a notification to cause an IDE to behave in any particular way, or even to be handled by the IDE at all.

A proxy may also use notifications, during a debug session, to let the IDE know about events that happen in the proxy. To do this, the proxy will have to listen for feature_set commands and keep track of the values set, as well as passing them through to the debugger engine.

IDE initialization of notifications:

feature_set -i TRANSACTION_ID -n notify_ok -- base64(1)

debugger engine notifications to IDE:

<notify name="notification_name">
TEXT_NODE or CDATA
<custom.../>
</notify>

8.6 interact - Interactive Shell

The interact command allows an IDE to send chunks of code to be compiled and executed by the debugger engine. While this is similar to the eval command, it has a couple important differences.

First, it buffers code sent to it until a successful compile is achieved. The buffering allows the IDE to send a line of code for each call to the interact command, which reflects a user typing code into a console. Each line is joined in the debugger engine with a newline character. As soon as a successful compile happens, the code is run and any output returned to the IDE (via stdout/stderr or otherwise).

Second, it returns a prompt string that can be used by the IDE as an input prompt for the user.

The interact command can only be called during a break or interactive state.

The debugger engine implementation MAY also be designed to work in and interactive-only mode, where there is no script being debugged, and all code is received through the interact command. This allows the protocol to be utilized for the purpose of a pure interactive shell for the language.

Control characters should be sent in the data section of the command, and the debugger engine should handle the control characters in a way that is expected by the implementation. These characters can include Ctrl-C (KeyboardInterupt in Python) and other such console like controls. The IDE should not expect the debugger engine to handle control characters in any specific way.

The IDE can query the debugger engine for interact support using the feature_get command.

The 'filename' in the stack for an interactive session should be '<console>' or some other string to denote a console stack level.

The debugger engine is not required to enable debugging of code recieved via the interact command, however it should provide access to other information, such as the variables retrieved via context_get.

IDE to debugger engine:

interact -i TRANSACTION_ID -m mode -- base64(code)

where,

-m mode

a mode of zero tells the interact command to clear the buffer and any other state that was maintained for previous interact commands. The prompt attribute returned should be an empty string.

debugger engine to IDE:

<response command="interact"
    transaction_id="TRANSACTION_ID"
    status="STATUS_NAME"
    more="CONTINUE_FLAG"
    prompt="PROMPT" />

where,

STATUS_NAME	A valid status name from the list of status names in section 7.1. A new name is added specificaly for this command which is 'interactive'. The interactive status is returned unless the mode in the command was zero, in which case the status will be up to the debugger engine (typically the last status before running interact), or some error has occured that causes a different status.
CONTINUE_FLAG	a boolean which is true if the interact command requires more code to compile successfully
PROMPT	a string containing the prompt for the next line of code