Remoting Architecture

From FirebugWiki

(Difference between revisions)
Jump to: navigation, search
(BTI & RDP)
Line 102: Line 102:
== BTI & RDP ==
== BTI & RDP ==
 +
This section summarizes the relation between '''BTI''' (Browser Toool Interface) and '''RDP''' (Remote Debugging Protocol). The diagram below is built on top of the previous diagrams on this page (see [[#Proxy|Proxy]], [[#Connection|Connection]] and [[#JavaScriptTool|JavaScriptTool]])
 +
 +
Before digging deep in how the remoting concept is designed, let's see what objects (entities) are already presented in the current architecture.
 +
Check out the red boxes in the diagram.
 +
 +
* ''NetMonitorModule'' This object is derived from ''Firebug.ActivableModule'' and represents the back-end service for Network Monitor tool.
 +
* ''NetPanel'' This object is derived from ''Firebug.ActivablePanel'' and represent the front-end for Network Monitor tool.
 +
* ''ScriptPanel'' Is derived from ''Firebug.ActivablePanel'' and represent the front-end for Script Debugger. The diagram doesn't show ''Debugger'' module, which represents the back-end based on JSD1. This module won't be necessary anymore since it'll be replaced by JSD2 API, JSD2 Actors and RDP (all already built-in Firefox platform).
[[image:Bti-rdp.png]]
[[image:Bti-rdp.png]]

Revision as of 07:42, 4 September 2012

This page is intended to summarize basic architecture concepts for Firebug (and Firebug extensions) remote capabilities (such as remote debugging or remote HTTP monitoring).

Contents

Resources

Proxy

The proxy object represents a connection between a panel (front end) and a module (back end).

The proxy has essentially two implementations:

  • Local - direct API calls
  • Remote - communication over TCP/IP protocol

Panel-proxy-module.png

  • Panel (a view) should never use Module (a service) directly
  • The communication should always be done through the current proxy
  • Each Panel should have its own proxy that implements API of the remote module (service)
  • There can be also proxy objects used by non-panel objects, e.g. the Profiler
  • It should be possible to create new proxies in extensions.
  • There should be also something like a default (or global) proxy that can be used for things like getting list of tabs on the remote browser


Here is a more detailed diagram with local and remote proxies.

Local-and-remote-proxies.png

  • Panel object at the top is referencing its proxy object
  • The proxy implementation can be local or remote
  • Local proxy uses direct API calls (in process) and asynchronous callbacks
  • Remote proxy uses TCP/IP connection to communicate with the back-end using JSON packets
  • The remote communication is based on RDP
  • The server side implements Actor, which is responsible for communication with specific proxy
  • The actor is finally consuming back-end Module (service) API

Connection

Connection object is responsible for sending properly setup packets to the server and handling all response packets. This object is also responsible for handling any errors (or error packets) that can occur during the communication.

Proxy-connection.png

  • Remote proxies should always use the connection object to send JSON packets
  • The connection is singleton it'll be probably attached to the global Firebug object

Server

Firebug also needs its server side implementation that will be used if Firebug is running in a server mode (on the remote browser). In such cases only back-end services like: NetMonitor or Debugger modules will be loaded and activated. UI overlays (i.e. browserOverlay.js) shouldn't be loaded at all since it isn't necessary and e.g. Fennec UI doesn't even have expected XUL elements to be overlayed.

Individual services should be always loaded on-demand at the time when appropriate actor is requested by the client side. For example, when the client side requests a net actor then NetMonitor module should be loaded and activated.

  • Only actors are registered on the server side by default
  • Actors are responsible for loading and activating back-end services
  • Extensions should be able to create and register custom actors
  • In order not to delay server side browser start-up time, we should delay loading of AMD modules till they are really requested by actors (e.g. the Net and Script panels don't have to be even enabled).

TabWatcher

Firebug TabWatcher is responsible for watching browser tabs events (open, close, switch) and firing further events to make sure that Firebug UI is properly updated and showing information related to the current page.

TabWatcher is clearly a server side component and as such it also needs a proxy. In case of JSD2 some events like tabNavigate might be server by API built-in in the platform.

BTI is implementing TabWatchListener (see browser.js file), which is listening to TabWatcher and forwarding all events to Firebug infrastructure. This object should be reused or removed not duplicated.

Tabwatcher-proxy.png


  • Local TabWatcher must be disabled when Firebug is connected to a remote browser instance

BTI

This section describes the current BTI (Browser Tools Interface) concepts. These concepts should be reviewed and refactored as necessary.

Browser

Proxy to a debuggable web browser. A browser may be remote and contain one or more JavaScript execution contexts. Each JavaScript execution context may contain one or more compilation units. A browser provides notification to registered listeners describing events that occur in the browser.

Bti-browser.png

WebApp

WebApp represents a browsing context. Browsing context is an environment in which Document objects are presented to the user. Instance of this object is associated with top level page window (it's on the same level as the context object).

This object doesn't implement any logic it's there only to demonstrate the concept.

JavaScriptTool

JavaScriptTool implements API related to script debugging. It serves similar purpose as a proxy object. It's currently placed between the Script panel and Firebug.Debugger module.

Bti-javascripttool.png

Compilation Unit

Describes a compilation unit in a browser context. A compilation unit may originate from a JavaScript source file or a script element in HTML. It's currently created when a new script is compiled (JSD).

CompilationUnit has:

  • list of breakpoints
  • url
  • reference to the current context

BTI Refactoring

Summary of suggestions for the current BTI architecture refactoring.

  • BTI.Browser should be renamed to BTI.BrowserProxy
  • Firebug.connection should be Firebug.proxy
  • Firebug.proxy.connection should refer to an object that is responsible for sending/receiving packets
  • A connection should be per context since one context can be connected to a local browser and another one to a remote browser.
  • firebug/lib/tool should be firebug/bti/tool

BTI & RDP

This section summarizes the relation between BTI (Browser Toool Interface) and RDP (Remote Debugging Protocol). The diagram below is built on top of the previous diagrams on this page (see Proxy, Connection and JavaScriptTool)

Before digging deep in how the remoting concept is designed, let's see what objects (entities) are already presented in the current architecture. Check out the red boxes in the diagram.

  • NetMonitorModule This object is derived from Firebug.ActivableModule and represents the back-end service for Network Monitor tool.
  • NetPanel This object is derived from Firebug.ActivablePanel and represent the front-end for Network Monitor tool.
  • ScriptPanel Is derived from Firebug.ActivablePanel and represent the front-end for Script Debugger. The diagram doesn't show Debugger module, which represents the back-end based on JSD1. This module won't be necessary anymore since it'll be replaced by JSD2 API, JSD2 Actors and RDP (all already built-in Firefox platform).

Bti-rdp.png

Personal tools