Editors - Debuggers - Browsers

[johnjbarton]

This topic is a summary of off line discussions with Mike Collins and
Ben Galbraith

Ultimately we want a protocol description and some libraries of
reusable code that realizes the protocol in interesting ways. To get
good reuse we need the components to be generic, but in the following
description I will use concrete examples and I'll let you generalize.

We want
+ --- Firefox
Bespin ---- Firebug ----+ --- Fennec
+ --- V8

The reason to put Bespin through Firebug rather than direct to the
browser is to allow Bespin users to use the Firebug UI for anything
Bespin does not want to deal with (yet). So for example, Bespin might
start with JS breakpoints but use FIrebug's stack control and
integration with DOM. Or Bespin may decide that it wants to focus on
editing and have the debug UI in firebug. Or Bespin may decide that
it wants to cut Firebug out altogether. These are all variations we
want to allow.

This model means two things: 1) we want Bespin to be able to get
partial debug support through the same protocol to FIrebug and to
browsers 2) we need some small extra work to deal with the fact that
both Firebug and Bespin are looking at the browser run time
simultaneously.

jjb

[Patrick Mueller]

The picture is making my head spin a bit.

I think what you are suggesting is one of either allowing Bespin to
run as a FireBug plugin of some kind, in which case it can make use of
FireBug's JS-accessible debug APIs, or somehow exposing such JS-
accessible debug APIs to arbitrary web apps (in this case, Bespin).

I'm in favor of this; I would like to see the JS environment extended
to include debugging capability, though there are presumably security
concerns that would need to be worked out. Whether this means
allowing an app to run in an existing debugger, or somehow providing
additional JS functionality to existing apps, doesn't matter too much,
I think.

The picture showing two browsers and one raw JS engine is interesting;
first, I think we want to extend the browser story to more browsers
than just Moz-based ones. :-) And I like the fact that a target here
is a non-browser environment. Being able to take advantage of the pre-
existing debuggers for non-browser environments would be fantastic,
since such debuggers are small in number today.

It also strikes me that we're talking about two separate sorts of APIs
here. One will be JS-accessible APIs to set breakpoints, peek at
stack frames, etc. Another is a wire format to be able to talk to JS
engines such as V8, or on a remote device (the Fennec story).

[johnjbarton]

Ok, my diagram was mixing things up. It actually represents a number
of scenarios.

[Bespin]---[Firebug|Firefox]
This one is my proposed starting point: Bespin in one process
talking to Firebug+Firefox in another. This scenario allows us to
explore the full range of any web debug protocol, as much as bespin
cares to deal with. Mike Collins from IBM is prepared to contribute
code the the Firebug side of this based on his work with DBGP, that is
to port the DBGP part to a new protocol.

[Firebug]--[Fennec]
Firebug (chromebug actually) in one process and machine, Fennec in
another. Important case to get to soon.

[Firebug]--[Firefox]
Proxy debugging for Firefox. Not much drive for this one but almost
free from the Fennec use case.

[Firebug]--[Chromium/V8]
Proxy debugging for V8. I guess the Chromium folks will have their
own debugger, so here the driver is more web devs who want one UI for
multiple browsers.

[Bespin]--[Firefox]
Here bespin has grown up and uses the same protocol without FIrebugs
help.

[FirebugA]-----\
[FirebugB]-----+---[Firefox]
Multiuser debugging.

In all of these cases the two ends of the wire are (probably) in
different processes.

Hope this is clearer,
jjb