[Seaside-dev] WAContext Refactoring

[Dale Henrichs]

Lukas Renggli wrote:

>Abstract
>
>We want to move a lot of responsibility that is currently in WASession
>and not global to the session (request, response, loadScripts, etc) to
>a newly created WAContext object.
>
>
>Problem
>
>If we have a look of at WASession there is a lot of functionality that
>does not belong there. #returnResponse: and #currentRequest are just a
>few examples. Additionally we have quite a few bugs [1] [2] [3] [4]
>[5] [6] that are hard to fix because we are hitting architecture
>limits of Seaside. The most common symptom is that we don't have
>information about things like request handlers where we need it.
>
>
>WAContext Solution
>
>The result of our todays experiments can be found in
>Seaside-Core-lr.110. A WAContext object that provides us with all the
>contextual information that we need:
>
>- the server, this is important for encoding especially it would allow
>us to do URL encoding for non-ASCII characters in a way that works
>independently of encoding settings
>- the current request
>- the current response, for stacking up cookies for example
>- a collection of request handlers, important for URL parsing
>- subscribers, for events like returning a response or rendering a component
>- properties for additional values like load scripts or the anchor name
>
>While delegating the processing requests request handlers would
>incrementally add themselves to the collection of request handlers. If
>the example of /seaside/tests/alltests two dispatchers, an application
>and a session.
>
>
>Problem with the Solution
>
>Currently used a dynamic variable to store the current context. That
>works fine as long as no continuations are involved. Actually the
>WAContext is unique to every request and should not be restored when a
>continuation is resumed. For a short moment we considered
>thread-locals but they again wouldn't work either because
>WAProcessMointor creates a new process. The next idea was to use
>partial continuations with a boundary that is below the dynamic
>variable that points to the current context.
>
>
>Consequences
>
>- we would lose the terminate functionality
>- ports would have to provide partial continuations, this might be a
>problem for some platforms whose continuation implementation differs
>substantially from Squeak
>
>Does anybody see problems with providing partial continuations on his
>platform? Does anybody see a better solution?
>
>  [1] http://code.google.com/p/seaside/issues/detail?id=13
>  [2] http://code.google.com/p/seaside/issues/detail?id=14
>  [3] http://code.google.com/p/seaside/issues/detail?id=16
>  [4] http://code.google.com/p/seaside/issues/detail?id=19
>  [5] http://code.google.com/p/seaside/issues/detail?id=21
>  [6] http://code.google.com/p/seaside/issues/detail?id=28
>
>Cheers,
>Philippe and Lukas
>  
>
I've just about finished adding process locals to GemStone and have 
added additional unit tests to make sure that GemStone's behavior with 
process variables and continuations matches Squeak behavior (and after 
the next compile cycle all of the tests should pass in GemStone:).

I have more work to do to get the new Seaside2.9 running on GemStone, 
but it looks like we're in good shape....

Dale