markstory · August 1, 2014 02:38
diff --git a/gistfile1.txt b/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.