[Seaside] session reference

[Stephen Pair]

Avi wrote:

> Yeah, I just looked at Runtime Environments.  They would 
> certainly do the trick, but it's an extra dependency and 
> using exceptions works fine (it doesn't handle forking as 
> cleanly, but then it doesn't make sense to fork the UI in 
> Seaside - or not in the traditional sense ;-).

Are you being too concerned about dependencies?  After all, you can
bundle up everything you depend on into a single installable thing.  No
big deal.

On a related topic, I thought about this issue of avoiding changes to
the base system (or more precisely, an external package) and I have a
couple more points about it:

Way back when, I tried to avoid changes to the base Squeak...eventually,
I gave up (and if you saw Squeak 4 years ago, you'd wonder why I even
tried)...what ended up happening is that all of the accumulated hacks
and work arounds that I had to do to avoid changing the base system
ended up being more of a liability that just making the changes.  Once I
freed myself and allowed myself to make changes to the base system, I
found that I was able to keep my stuff a lot cleaner than I otherwise
could have.  And I discovered that it was actually very easy to keep in
sync with the base release.  The other thing that I realized is that no
matter what you do (composition, subclassing, or patching), you depend
on the base Squeak, and when it changes, you have a maintenance task. 

So, the best thing was to isolate my stuff, have periods of time where I
froze the version of Squeak I was using, and have a controlled update
procedure.

Also, that was before Sunit...once Sunit came into the picture, I found
that I could use my tests to identify any cases where changes coming
down the update stream broke my code.  Now it was literally only taking
a few minutes to fix up any discrepancies coming from SqC.  

And, now that we have this SqueakMap playground where everyone is
putting their stuff...people are much more likely to test package X with
package Y and discover places where things don't quite line up and fix
them.

Then, enter DVS and suddendly I have a nice way of separating the things
that belong in a package and the things that have to change in other
packages (i.e. base Squeak) in order for my package to work.

And, finally we have SAR, which enables me to bundle up my things and do
some intelligent examination of the environment in which I'm loading a
package into...for example, my SARs will check for any dependencies when
they get loaded.  Kats will not load if Runtime Environments (and a few
other packages) are not present in the image.

Eventually, I'll get around to setting up a nightly fetch, build, load,
and test job...which should make the maintenance task that much easier.

Wow, that turned into quite a tangent...back to sessions, etc:

> One thing that interested me about Runtime Environments was 
> that it is extremely close to the StateFrame that Seaside 
> uses to manage backtrackable object state (does Kats use RE 
> in the same way?).  The main difference, I think, is that 
> once you create a child StateFrame the parent becomes 
> immutable, and its associations get copied down into the 
> child to avoid long lookup chains.  I then create a new child 
> state every time a continuation is resumed.  If you can think 
> of a way of unifying those two, I'd like to hear it.  The 
> Runtime Environment is quite likely something that would want 
> to backtrack in sync with continuations, after all.

Kats itself doesn't do backtrackable state, but rather, I use Kats to
implement backtrackable state.  I create a clone of the active
transaction (along with a copy of the context stack) at each interaction
point (cloning a transaction means copying the transaction as well as
the state of the modified and dirty objects).  When I back track, I
simply make the cloned transaction the active transaction (which means
that anything done after the clone is no longer active).

Kats uses RE to maintain the notion of an active transaction...for
example, the code for BlockContext>>valueInTransaction: is

	Env clamp:
		[Env transaction: aTxTransaction.
		^self value]

...and #transaction: is just a kats extension method to RE, which
basically does:

	Env at: #txTransaction put: aTxTransaction.

This is very similar to the effect you get with exceptions, except that
you use "Env" to access your environment state instead of singaling an
exception.  The #clamp: in the above example ensures that the
environment is restored to its original condition after the block
finishes.

So, to implement backtrackable state for WAComponent in this scheme, I
would only need to make WAComponent "transaction aware" and do away with
the use of a StateFrame.

Stopping short of making a WAComponent transaction aware, you could
manage your StateFrames using Runtime Environments (by manage, I mean
use RE to govern which StateFrame is active at any given time).  In that
case, your StateFrame starts to look very much like a
TxTransaction...except that you are mixing transaction control and state
management into one object (when you get into coordinating distributed
transaction...over a series of SOAP interactions for example; separating
transaction control from state management becomes more important).

When I start to redo my stuff in Seaside, I'll probably try and make
Seaside's WAComponent capable of using Kats *or* StateFrames.  There's
also a whole other issue that I'm tackling right now with Kats in trying
to make it work with objects that use the IvapParser or objects running
on the Chango-PVM.  I think Kats is getting much better (simpler and
cleaner) as a result.  On a side note: it's real handy having 45 Sunit
test for Kats.

- Stephen