Debugging infrastructure architecture
Structure
An architecture that meets the requirements is as follows:
+--------------------+ tcp/ip, +-----------+
| | shmem, +------| Front-end |
| +---+ ... | +-----------+
| +----------+ | N | v
| | Back-end |---->| U | +-----+
| +----------+ | B | | |
| | |------------->|Proxy|
| +----------+ | | tcp/ip, | |
| | Back-end |---->| | shmem, +-----+
| +----------+ | | ... ^
| +---+ | +-----------+
| | +------| Front-end |
+--------------------+ +-----------+
Opera Debugging clients
The important points of this design are:
- Tools are split into back ends which reside in Opera, and
front ends which reside elsewhere.
- Inside Opera, the tool back ends register themselves with a tools
manager ("NUB") that resides in the scope module, and communicate
through that manager.
- Outside Opera, front ends handle the user interface, control, and
other aspects that can be moved out of Opera proper.
- Opera and the tool manager both connect to a single proxy which
acts as a hub in the system, and manages communication and data
distribution.
- Multiple front ends can communicate with multiple back ends. For
example,
- the memory logger front end can interact with both the
malloc back end (for allocation summaries) and the ecmascript
back end (for garbage collection events);
- while the ecmascript
debugger front end can communicate both with its own back end and
with the DOM inspector's back end.
- The communication channels can be anything from a network to
shared memory, depending on the platform's abilities and how
much bandwidth a tool needs.
- With just a small amount of abstraction the proxy will become
invisible to both back ends and front ends, so particularly
data-intensive tools can move into Opera, be part of the Opera UI,
and still use the same framework.
- How functionality is split between a front end and a back end
depends on the tool; it is not something that is restricted to a
great extent by this architecture.
- Since communication can be via a network connection, front ends
can be written in whatever language the tool author chooses.
- Since Opera connects to the proxy over a single connection, even
embedded versions of Opera (eg on phones) can be debugged because
there is no need for the tool to be able to connect to the phone
directly.