Derek Brans wrote:

> I have had a look at the examples and documentation.  I think my 
> programming could be greatly aided by using RE's.
> 
> I haven't quite got my head around the pattern yet.  Where's a good 
> place in an application to define an RE?

You don't necessarily need to "define a RE"...if the runtime variable(s)
you need to access are only created and accessed in a single process or
processes forked after the variable is defined, then the pattern is
simple.  Take the case where you want to have access to the httpRequest
that a process is serving...the code might look like:

SomeClass>>serve: anHttpRequest

   Env clamp:
      [Env at: #httpRequest put: anHttpRequest.
	someObject processTheHttpRequest].

In this case, #clamp: ensures that the environment will be restored to
it's original condition after block executed.  We then set the
environment variable #httpRequest.  And you can access #httpRequest
anywhere in the code for #processTheHttpRequest (or methods that it
calls, and in processes that it forks).  You access the httpRequest
using:

   Env at: #httpRequest

So, in this simple case, there is no need to "define an RE".

> Take a Seaside application for example.  Suppose that a given 
> application had some information that needed to be available to all 
> objects used by the application's process (starting with the 
> entryPoint).  Where would I define the RE for that application?

RuntimeEnvironments is also designed to handle this situation.  If your
application needs to access some global state, however you'd like to
support multiple instances of that application, which may need different
values for that global state, then RuntimeEnvironments is probably a
good solution.  A similar pattern exists in Morphic in the way it refers
to certain globals like "Project current", UIProcess, Sensor, etc.
Morphic could use RuntimeEnvironments to enable multiple Projects to be
simultaneously active in a single Squeak session.   
 
In terms of Seaside with Comanche, a good place to maintain a runtime
environment is with your (subclass of) ComancheNetService.  You would
create and maintain a "SharedRuntimeEnvironment", and then associate
that RE with any processes that the ComancheNetService starts/stops.
When the ComancheNetService forks off other processes, the RE will be
adopted by those processes.  When you make changes directly to that
SharedRuntimeEnvironment, all processes that use that RE will see those
changes.  In contrast, changes made with the runtime environment
accessor, Env, are only visible to the active process (and any processes
that are subsequently forked).  Here's an example :

YourNetService>>initialize

   myRuntimeEnvironment := SharedRuntimeEnvironment new.
   myRuntimeEnvironment at: #someVar put: #someValue.
   myProcess := [self serviceLoop] newProcess.
   myProcess env: myRuntimeEnvironment.

In this case, in myProcess, you'll be able to access #someVar using "Env
at: #someVar"...any processes that are forked by #serviceLoop will also
be able to see that variable.  If you make changes directly to your RE,
all processes using that RE will see those changes.

> Also, would it be practical to store a RE in a MinneStoreDB or 
> SmartFileDictionary?

I don't see any reason why not as long as you can reasonably persist the
variables in your RE.

- Stephen