markstory/gist:3e1d48885e9fdceef706

## gistfile1.txt
Idea for future DebugKit.

The current debug kit does a bunch of things right, but has a few short comings that are hard to address in the current design:

* DebugKit is slow - generating the HTML for the toolbar in the originating request is not fast, and DebugKit bloats every request with mountains of HTML.
* DebugKit is easily disrupted by the host page CSS - Having DebugKit on the host page means it is difficult to deliver an excellent UI for debugkit as it frequently gets interference from the host page.
* The History Panel is fragile and relies on Cache being enabled.

I think many of these problems can be solved with a few key changes:

* DebugKit should live in an iframe. This solves the CSS limitations.
* DebugKit should store data in a SQLite database. Page results should be stored in a small SQLite database, this will allow panel contents to be fetched asynchronously on demand allowing the host page to remain light.
* DebugKit should not use a Component, instead it should use a DispatcherFilter to register a series of event listeners that allow it to instrument and augment the relevant application sections.

I see a path to these goals with the following plan:

* [ ] Remove the history panel in its current form. Add the SQLite storage of data. Data will be persisted in the `Controller.shutdown` event, or as a `register_shutdown_function`.
* [ ] Make panels load asynchronously. Instead of being rendered on the host page, panel HTML is loaded by XHR requests.
* [ ] Replace the ToolbarComponent with a set of event listeners that collect the relevant information. Panels will be attached to events as they need.
* [ ] Put the panel in an iframe and use a minimal javascript file to bootstrap the UI for DebugKit.
* [ ] Refresh the design of DebugKit to be more modern and current.

At each step of the way tests should be updated and expanded as needed. In addition to these changes I think the following cruft should be removed:

* FirePHP - It is rarely used and if the panels store all data in SQLite we can easily get panel data on any subsequent HTML bearing request.
* DebugKitDebugger - it serves no real purpose anymore.
	Idea for future DebugKit.

	The current debug kit does a bunch of things right, but has a few short comings that are hard to address in the current design:

	* DebugKit is slow - generating the HTML for the toolbar in the originating request is not fast, and DebugKit bloats every request with mountains of HTML.
	* DebugKit is easily disrupted by the host page CSS - Having DebugKit on the host page means it is difficult to deliver an excellent UI for debugkit as it frequently gets interference from the host page.
	* The History Panel is fragile and relies on Cache being enabled.

	I think many of these problems can be solved with a few key changes:

	* DebugKit should live in an iframe. This solves the CSS limitations.
	* DebugKit should store data in a SQLite database. Page results should be stored in a small SQLite database, this will allow panel contents to be fetched asynchronously on demand allowing the host page to remain light.
	* DebugKit should not use a Component, instead it should use a DispatcherFilter to register a series of event listeners that allow it to instrument and augment the relevant application sections.

	I see a path to these goals with the following plan:

	* [ ] Remove the history panel in its current form. Add the SQLite storage of data. Data will be persisted in the `Controller.shutdown` event, or as a `register_shutdown_function`.
	* [ ] Make panels load asynchronously. Instead of being rendered on the host page, panel HTML is loaded by XHR requests.
	* [ ] Replace the ToolbarComponent with a set of event listeners that collect the relevant information. Panels will be attached to events as they need.
	* [ ] Put the panel in an iframe and use a minimal javascript file to bootstrap the UI for DebugKit.
	* [ ] Refresh the design of DebugKit to be more modern and current.

	At each step of the way tests should be updated and expanded as needed. In addition to these changes I think the following cruft should be removed:

	* FirePHP - It is rarely used and if the panels store all data in SQLite we can easily get panel data on any subsequent HTML bearing request.
	* DebugKitDebugger - it serves no real purpose anymore.