> Thus is it a generic specification on top of and adjunct to WSGI > specification, not a lump of code which binds you to Apache. The > intent being that it would be a generic mechanism for passing data > which can equally be used by other WSGI components for providing the > functionality.
I think the key statement from the first e-mail was this: > The simplicity of how mod_session uses HTTP_SESSION variable on input > to application to provide session information and a response header > for data to be stored back to the session database when request > complete fits quite well with WSGI way of thinking and if existing > solutions could be modified to support this way of doing things, it > would make it really quite easy to have a WSGI application to delegate > such responsibilities back to Apache to do it. This is certainly true, and I think that it should be a reasonable task to make a repoze.who/what backend which uses this mechanism. But it's harder to figure out how this could work with Beaker for regular session data, but I think it might be possible to write something that set's response headers when you call .save() on the session dictionary, and thus provides an alternative beaker back-end which works with apache sessions. I'm a bit hesitant to break backwards compatibility with the current Beaker API, since there is a good amount of time/thought/energy invested in that at this point. --Mark Ramm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
