Firebug 1.7: Architecture Refactoring
- 1 Problems to be Solved by Refactoring
- 2 Proposed Changes
- 2.1 Separate Modules and Panels
- 2.2 Components replaced by SharedObjects
- 2.3 Recode TabWatcher -> DOMWindowWatcher
- 2.4 Sandboxed Extension Loading
- 2.5 Refactor debugger.js <-> firebug-service.js API
- 2.6 Workplan items (not yet in order)
- 3 How to participate
Problems to be Solved by Refactoring
- Prepare to support remote debugging for mobile and multiprocess browser
- Server side will be headless
- Client side will have no access to Firefox data
- Allow simpler and more robust extensions
- Isolation and concentration of extension code
- Clean up expedient code and clarify the implementation
- relation to platform window system
- relation of panels and modules
- prepare/exploit shift to jetpack
Separate Modules and Panels
Broadly speaking Mike Collins' architecture for remote Firebug puts the module code in the server and the panel code in the client (UI side). The Firebug 'context' object (TabContext.js) is passed over the wire between them using CrossFire.
The first step in that direction is to divide all of the source into module and panel files. For example we might have debuggerModule.js and debuggerPanel.js. Then firebug.js would be divided between module dispatch and panel dispatch (dispatchModules.js and dispatchPanels.js?). The API between these objects would be the API CrossFire would remote.
Issue: file names vs folders
I understand the natural appeal of module/debugger.js and panel/debugger.js vs debuggerModule.js and debuggerPanel.js. However in my experience one needs to write with one kind of module plus panel much more often than all of the panels or all of the modules. Creating a subdirectory for each feature, eg debugger/module.js make lots of small folders. Any scheme where the folder is used to disambiguate makes lots of tools hard to use because you end up with a lot of UI selections like "module.js" or "debugger.js" and you can't tell what it means. That is how I ended up with debuggerModule.js and debuggerPanel.js: unambiguous naming with the feature first so alphabetic sort groups by feature.
Leverage work by CommonJS
This would put us on the same path as jetpack proposals.
As far as I know the CommonJS, as well as Mozilla platform Components.utils.module, supports common code loading, but we want common object sharing. So there may be some additional work on API.
Recode TabWatcher -> DOMWindowWatcher
I think we now pretty much understand TabWatcher, but it is still very heuristic and relies on Firefox idiosyncrasies that can change. Chromebug has its own watcher and even more guesses about the platform. Let's replace all of that with a clean abstraction for nsIXULWindow and nsIDOMWindow lifetime event notifications. Then put it in a SharedObject so we only need one per application and we have clearer API.
This requires platform support
Issue: DOMWindowWatcher API
Ideally we would mimic/influence jetpack here, as they have a subset of the same problem.
Sandboxed Extension Loading
By re-applying the module loading technology we can create a jetpack-like environmental wrapper for Firebug extensions. The extensions would be slightly simpler because they would just be zip files. They would be slightly more robust, because they would be evaled in a scope that only contains Firebug.
Refactor debugger.js <-> firebug-service.js API
Ultimately we want debugger.js to split into a front-end and back-end, with the back-end implementing Crossfire's V8-like protocol. So a start is to shift work between debugger.js and firebug-service.js to be an V8-like API, and use firebug-service.js as an adapter between V8-like protocol and Mozilla jsd. (Note that JSDebugv2 aka js::dbg should have this kind of API).
- D8 source (V8 command line tool)
- v8-debug.h header file for V8 debugger API
- V8 debugger protocol
Workplan items (not yet in order)
- Define a new interface Firebug.Middle
- Functions equivalent to the Crossfire protocol
- Define new module mozilla-backend.js
- Implements Firebug.Middle using jsd
- Define new module crossfire-client.js
- Implements Firebug.Middle using Crossfire
- Define new Firefox extension CrossfireJSD
- Implements Crossfire server, calls mozilla-backend.js
- Reimplement debugger.js to calls into Firebug.Middle instead of fbs.
- At load time Firebug.Middle is implemented using either mozilla-backend.js or crossfire-client.js
- Implement FBTest.Middle
- js unit tests that call into Firebug.Middle
- FBTest configuration to test mozilla-backend.js and crossfire-client.js looping through server