Confirmed users
497
edits
Remote Debugging Protocol: Difference between revisions
Jump to navigation
Jump to search
Actor names are now strings, not numbers.
(→Objects: Add request for accessing function scopes.) |
(Actor names are now strings, not numbers.) |
||
| Line 14: | Line 14: | ||
For example, a debugger might connect to a browser, ask the root actor to list the browser's tabs, and present this list to the developer. If the developer chooses some tabs to debug, then the debugger can send <tt>attach</tt> requests to the actors representing those tabs, to begin debugging. | For example, a debugger might connect to a browser, ask the root actor to list the browser's tabs, and present this list to the developer. If the developer chooses some tabs to debug, then the debugger can send <tt>attach</tt> requests to the actors representing those tabs, to begin debugging. | ||
Actor names are JSON strings. The name of the root actor is <code>"root"</code>. | |||
To allow the server to reuse actor names and the resources they require, actors have limited lifetimes. All actors in a server form a tree, whose root is the root actor. Closing communications with an actor automatically closes communications with its descendants. For example, the actors representing a thread's stack frames are children of the actor representing the thread itself, so that when a debugger detaches from a thread, which closes the thread's actor, the frames' actors are automatically closed. This arrangement allows the protocol to mention actors liberally, without making the client responsible for explicitly closing every actor that has ever been mentioned. | To allow the server to reuse actor names and the resources they require, actors have limited lifetimes. All actors in a server form a tree, whose root is the root actor. Closing communications with an actor automatically closes communications with its descendants. For example, the actors representing a thread's stack frames are children of the actor representing the thread itself, so that when a debugger detaches from a thread, which closes the thread's actor, the frames' actors are automatically closed. This arrangement allows the protocol to mention actors liberally, without making the client responsible for explicitly closing every actor that has ever been mentioned. | ||
| Line 33: | Line 35: | ||
{ "to":<i>actor</i>, "type":<i>type</i>, ... } | { "to":<i>actor</i>, "type":<i>type</i>, ... } | ||
where <i>actor</i> is the actor to whom the packet is directed | where <i>actor</i> is the name of the actor to whom the packet is directed and <i>type</i> is a string specifying what sort of packet it is. Additional properties may be present, depending on <i>type</i>. | ||
Every packet sent from the server has the form: | Every packet sent from the server has the form: | ||
| Line 110: | Line 112: | ||
|- | |- | ||
| ({x:1}) | | ({x:1}) | ||
| { "type":"object", "class":"Object", "actor":24 } | | { "type":"object", "class":"Object", "actor":"24" } | ||
|} | |} | ||
| Line 331: | Line 333: | ||
When the connection to the server is opened, the root actor opens the conversation with the following packet: | When the connection to the server is opened, the root actor opens the conversation with the following packet: | ||
{ "from": | { "from":"root", "application-type":<i>app-type</i>, "traits":<i>traits</i>, ...} | ||
The root actor's name is always zero. <i>app-type</i> is a string indicating what sort of program the server represents. There may be more properties present, depending on <i>app-type</i>. | The root actor's name is always zero. <i>app-type</i> is a string indicating what sort of program the server represents. There may be more properties present, depending on <i>app-type</i>. | ||
| Line 339: | Line 341: | ||
For web browsers, the introductory packet should have the following form: | For web browsers, the introductory packet should have the following form: | ||
{ "from": | { "from":"root", "application-type":"browser", "traits":<i>traits</i> } | ||
== Listing Top-Level Browsing Contexts == | == Listing Top-Level Browsing Contexts == | ||
| Line 345: | Line 347: | ||
To get a list of the top-level browsing contexts (tabs) present in a browser, a client should send a request like the following to the root actor: | To get a list of the top-level browsing contexts (tabs) present in a browser, a client should send a request like the following to the root actor: | ||
{ "to": | { "to":"root", "type":"list-contexts" } | ||
The reply should have the form: | The reply should have the form: | ||
{ "from": | { "from":"root", "contexts":[<i>context</i>...], selected:<i>index</i> } | ||
The <tt>contexts</tt> property's value is an array with one element for each top-level browsing context present in the browser, and <i>index</i> is the index within that list of the browsing context the user is currently interacting with. Each <i>context</i> has the following form: | The <tt>contexts</tt> property's value is an array with one element for each top-level browsing context present in the browser, and <i>index</i> is the index within that list of the browsing context the user is currently interacting with. Each <i>context</i> has the following form: | ||
| Line 363: | Line 365: | ||
For example, upon connection to a web browser visiting two pages at example.com, the root actor's introductory packet might look like this: | For example, upon connection to a web browser visiting two pages at example.com, the root actor's introductory packet might look like this: | ||
{ "from": | { "from":"root", "application-type":"browser", | ||
"contexts":[ { "actor": | "contexts":[ { "actor":"context1", "title":"Fruits", | ||
"url":"http://www.example.com/fruits/" }, | "url":"http://www.example.com/fruits/" }, | ||
{ "actor": | { "actor":"context2", "title":"Bats", | ||
"url":"http://www.example.com/bats/" }]} | "url":"http://www.example.com/bats/" }]} | ||