Notes on Examine Manager
--------------------------

(A) Introduction

The Examine Manager is a set of C++ classes that provide some useful 
services to examine packages. The idea is to free the examine developer from
the need to handle generic tasks and tasks that require a high level of 
technical expertise such as serving histograms to (possibly) remote processes.
Ideally, the examine developer need focus only on unpacking relevant data and
providing histograms that aid in assessing the integrity of the data as they
are acquired. 


(B) Overview

We anticipate the need both for synchronous and asynchronous interaction 
with examine packages. A typical synchronous interaction is sending an "update"
message to a histogram browser. Another would be a request to "book" a new
histogram. These interactions are synchronous because they require action that
occurs in the event loop of an examine package, either "filling" histograms
and then sending an "update" message, or "booking" new histograms on-the-fly.
It seems unnecessary to act on such requests at a rate greater than that at
which events are read into an examine program. 

On the other hand, it would be frustrating to have a histogram browser blocked
because it is waiting for an update that never comes, or does so infrequently.
Therefore, one anticipates the need for an object, within an examine program,
that runs in a separate thread of control from that of the event loop, whose
job would be to respond immediately to requests from a histogram browser. That
object (the request broker, which is part of the suite of Examine Manager 
clases) presumably would cache the requests from the browser for later action 
by the examine package and inform the browser that the request has been noted. 
The D0Scan program is a good example of the dual-thread model we wish to 
emulate.

In order to achieve the goal of keeping examine packages uncluttered by 
code to handle requests directly we shall make it the responsibility of the
Examine Manager to translate the browser requests into RCP objects that can
be accessed in the usual straightforward way by examine packages. Ideally,
the examine package would be strictly blind as to the provenance of these
RCP objects: they could have come from an RCP script or created dynamically
by the Examine Manager.  

(C) Structure of Examine Packages

The existing examine packages are not designed to handle the creation of
histograms on-the-fly. In some packages, for example MuoExamine, there are
provisions to allow the resetting of histograms. We should devote some 
thought to the re-design of examine packages to allow for the dynamic 
manipulation of histograms (creation, resetting, etc.).


(D) What Exists

    1. Root_gui
    2. eBrowser
    3. ExamineMgr (synchronous part)
    4. Several examines, each written differently!

Clearly we would like to make use of all of the above in some way. That needs
discussion and thought.