[Seaside-dev] WAContext Refactoring

[Lukas Renggli]

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

-- 
Lukas Renggli
http://www.lukas-renggli.ch