[Seaside] comanche modules design

[Stephen Pair]

Hi everyone...sorry to post a Comanche question on this list, but the 
main squeak list is too flooded right now and I think most people who 
would be interested in this are on the Seaside list.

I'm in the process of thinking about how to re-introduce the concept of 
modules in ComancheNG.  There are a few modules that I'm going to start 
with like Chieftain (for matching routing based on url paths), Session 
(for managing client sessions), something to manage virtual domains, and 
probably something akin to apache's mod_rewrite (though far simpler) for 
doing basic request transformations.  I think with this set of modules 
as a start, I'll have a fairly good representation of the kinds of 
things a module might want to do.

In ComancheNG, objects that respond to #processHttpRequest: are 
considered "modules"...and, I've extended Block and MessageSend such 
that they respond to #processHttpRequest:.  ComancheHttpService now 
dispatches #processHttpRequest: to its "plug" instance variable if it is 
not nil.  The following is a  rough sketch of how I envision one 
creating an http server configuration (it's only a rough outline for 
example):

 (ComancheHttpService on: 8200 named: 'MyWebServer')
    dispatchTo:
        (ChieftainModule new
            mapPrefix: '/displaycam' to: DisplayCamModule new;
            mapPrefix: '/helloworld' to: HelloWorldModule new;
            mapPrefix: '/seaside' to: WAKomNG new;
            mapPrefix: '/myotherapp' to:
                (ComancheSessionModule new
                   dispatchTo: MyOtherApp new;
                   yourself);
            yourself)
    start


The question that I'm most interested in is how to handle accessing the 
request, response and session (created by ComancheSessionModule).  
Currently, #processHttpRequest: passes the request in, and expects an 
HttpResponse as the answer.

With ComancheSessionModule, it is necessary not only to examine the 
HttpRequest, but also to create or lookup a session and make it 
available to subsequent modules and potentially modify the response (if 
you are using cookies to track sessions).  We can modify the response in 
the ComancheSessionModule (on the way out) when it is passed back to 
us.  However, how should I pass along the session information?

a) make the session an inst var of the request (don't really like this 
option)?
b) make any subsequent modules implement a #processHttpRequest:session: 
method (don't like this either)?
c) use a DynamicBinding to store the current session (I prefer this)?

I don't like "a" because it is adding new capability to HttpRequest, 
which I think needs to be as clean and simple as possible.  I don't like 
"b" because potentially every module will need to implement that method 
so that it will be able sit behind a ComancheSessionModule.  Going with 
option "c", accessing a session could look like any one of the following:

1.  #httpSession binding
2.  Bindings at: #httpSession
2.  HttpSession current
3.  HttpSession binding

...I like option 2 because it is a familiar pattern, however using a 
method named #binding (as in option 3) would give a reader a clue that 
they are accessing a dynamic binding (as opposed to a simple class var).

Finally, if I am going use a dynamic binding to store and access the 
session, should I do the same with the request and response?  If I use a 
dynamic binding to store the response, then should I have 
ComancheHttpService create and bind the response?  Or, should 
'HttpResponse binding' do lazy initialization of a response?  I could 
even change #processHttpRequest: to #processHttpRequest (since you can 
get at the request through the dynamic binding).

My tendency here is to make the request avaialable as a dynamic binding 
(through 'HttpRequest binding'), do lazy initialization of 'HttpResponse 
binding', and keep the current protocol of #processHttpRequest: (where 
the returned HttpResponse is what gets sent to the client).

Any thoughts?

- Stephen