1.  Make sure any calls to dlsym/dlopen etc. go through portable code
    currently found in common/plugin.

2.  Right now, the environment still has to be set up manually.

3.  This includes things like the LD_LIBRARY_PATH.  Solutions:
  a)  There is some code in sim.C for setting up the LD_LIBRARY_PATH
      then re-exec'ing itself so the loader gets the new path.  It
      does not go through enough logic to get the right paths, though.
      This solution partly breaks profiling and debugging, however.
  b)  The engine wrapper could be linked against the full paths of the
      visit libraries.  This requires it to be built after visit has
      been publicly installed.
  c)  We can dlopen the dependent libraries, in reverse order, with the
      RTLD_GLOBAL flag or'ed in.
  d)  We could, of course, simply provide a script for users to run
      before ARES to set up their environment.


4.  This all needs to be tested for portability.

5.  Related to 3a, there is a RTLD_GLOBAL flag set in sim.C when loading
the engine wrapper library.  This is necessary on sunos (maybe elsewhere)
so that all the libraries the engine wrapper library was linked against
will be made available to plugins (and other libraries?) as they are
loaded.  After Silo could not find -lsocket, however, I simply fixed it
using RTLD_GLOBAL without seeing what else failed.  Maybe when we get
rid of all the database plugins in the simengine and Silo goes away, this
won't bite us anymore?  (It probably will, but I don't know for sure.)

6.  Control-C handler is overridden by engine.  This is bad.  We also need
to think about what else the engine is overriding (e.g. other signal
handlers).

7.  Think about security of who's allowed to talk to whom.

8.  On linux:
    a)  without -lpthread, it stalled down in vtkWriter waiting on a
        file mutex!  (This is while it was trying to construct a vtk
        data object string to return the geometry to the viewer.)
        Further update:  It stalled with -lpthread as well, just in
        different ways.  I found that it seemed to be stalling on the
        line of code:
            *fp << "%%";
        And changing it to a 
            *fp << strdup("%%");
        may have fixed the problem.  I'm not convinced this isn't a
        gcc296/glibc problem.  And removing pthreads from VTK may fix
        it as well.  (why are they there, anyway?).  There also may
        still be a serious memory bug causing this, but I haven't moved
        back to the suns to try it out yet.
    a2) CLARIFICATION -- Found out the problem....  if the dependent
        libraries depend on -lpthread, but the main executable does
        not, then it will hang somewhere in the iostream stuff.  The solution
        is to make sure the main executable is also linked with pthreads.

    b)  without -rdynamic on the link line for the binary, we
        couldn't see symbols in the main executable, either through
        "extern int *p_ns;" or through "dlopen(NULL, ...) ....".

    b2) --export-dynamic also solves this.  Same symptoms, etc.  Maybe
        it's the same flag?

-------------------------------------------

TODO:

1) security
2) if the simulation is running, stop requests to the engine:
   either (a) have Engine return error conditions
   or     (b) have EngineProxy return error conditions
   or     (c) have the simulation pause
3) simulation controls window and interfaces (pause, start, auto-update)
4) get parallel working
5) QvisGUIApplication::HandleMetaDataUpdate is a bit too manual right 
   now -- e.g. it manually calls Update on the file information window
   and the plot manager widget.  We might be able to have these happen
   automatically by having the right things observe the right attributes.
6) test updating SILs
