[Web-SIG] Standardised configuration.

[Alan Kennedy]

[Alan Kennedy]
 >> I originally thought that option B was the best, but now I think
 >> differently. And from what I read from your post, Paul, I think
 >> we're in agreement.

[Paul Boddie]
 > Are we? ;-) Certain things like sessions are most likely to be
 > configured in the server environment. In Tomcat, for example, that
 > would be in one of the XML configuration files, but for something
 > like Apache/mod_python it would be nicest to use httpd.conf or a
 > related file, and Webware and Zope store sessions in their own
 > particular way - note that Zope uses its own special mechanisms
 > which might not correspond exactly with the conceptual model you
 > envisage.

Ah, now we're getting somewhere.

I think that session handling is an excellent example against which to 
have this discussion. Note however that I am *not* advocating 
standardising session management under WSGI.

J2EE session handling is generally a huge PITA, primarily because the 
base unit of session management is the servlet context, i.e. every 
servlet context gets its own "session space". For example

'/forms' may map to one session space, while
'/news' may map to a different session space.

Any given user may have multiple sessions on a server, depending on the 
number of servlets they have interacted with. It is generally not 
possible, except using container specific methods, to have a single 
"uber-session" which concentrates all user session data into a single 
object. This "hierarchy problem" makes it difficult, and extremely 
container-specific, to manage a single set of users across a set of J2EE 
servlets.

Most J2EE containers support both cookies and URL rewriting for session 
management, i.e. if the user-agent has cookies disabled, then all urls 
are rewritten to contain sessions IDs. Which means that the url 
rewriting algorithm has to be aware of multiple servlet contexts, and 
rewrite local urls to contain the session ID which is specific to the 
target context/servlet.

Some J2EE containers support a "Single Sign On" facility, where the 
container manages the multiple session objects on the applications 
behalf, and makes it easy for the user (but not the programer) by only 
making them sign on to a server once. Tomcat does this using an extra 
cookie, the SSO cookie, which is transmitted to user-agents *as well as* 
the per-servlet cookie, i.e. the user-agent receives two cookies from 
the container. Worse, the Tomcat Single-Sign-On facility does not 
support URL rewriting: the user-agent *must* have cookies enabled in 
order for single sign on to work. Which sucks.

I think that if WSGI applications were to rely on the local 
platform/container session management facilities, it is extremely 
unlikely that they would be portable. It's difficult enough to get 
coherent cross-servlet session-handling working on J2EE when writing in 
java, as these pages show

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/host.html#Single%20Sign%20On
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/valve.html#Single%20Sign%20On%20Valve
http://www.fwd.at/tomcat/sharing-session-data-howto.html

Imagine the complications if the application code were originally 
written to work with say, WebWare under cpython?

To me, session handling is one of those things that is done in so many 
different ways by so many different platforms/containers that it is 
impractical to achieve application portability once a particular 
methodology has been chosen.

So, IMHO, session handling is one of those "should be simple" areas of 
web programming that gets horrifically complicated when trying to move 
applications between platforms/containers: in fact I'd go so far as to 
say the multiple session handling techniques is one of the primary 
reasons why the python web world is currently so fragmented: every 
framework author thinks they know best: although some do it much better 
than others. I like webwares method of using URL path parameters, with a 
auto-refresh if a request is received that doesn't contain a session ID. 
But IIRC, this method is quite Apache specific, and requires 
modification of the Apache httpd.conf to get working. I could be wrong 
though.

It is important to note that I am *not* advocating standardising session 
management under WSGI: far from it. But what I am advocating is trying 
to make it as easy as possible for session-handling middleware 
components to be as portable between WSGI servers as possible. WSGI, as 
it currently stands, makes it far easier to do this than any other 
approach: I'm just trying to foresee and eliminate the last few % that 
stands in the way of 100% portability.

Regards,

Alan.