No problem, since I'm writing the CLAW manual, this is definitely in scope, I'll write down the documentation of my changes to session handling for realm support (this weekend I think, if it's not too late for you). If you think, I can also zip the project so that you can also see how the session things work in concrete.
kiuma
On Thu, Apr 10, 2008 at 1:54 PM, Hans Hübner hans@huebner.org wrote:
Hi Ralf,
can you come up with concrete examples of what could be configured with Hunchentoot and mod_lisp that would not be possible in a mod_proxy setup? I am relatively easy to convince that keeping mod_lisp support is a good idea, but I'd still want to know what exactly these advantages are.
With respect to other comments:
I do like the idea of using a streams based approach to mod_lisp and raw http support, as Arjan has suggested. I am not sure if I will make this change soon, though, and if I could start by removing mod_lisp support, it would make life easier for me as well.
It would be helpful if Robert and/or Andrea could write down how session support needs to be enhanced.
Thanks, Hans
Thanks, Hans
2008/4/9, Edi Weitz edi@agharta.de:
On Wed, 09 Apr 2008 17:24:30 +0200, Ralf Mattes rm@seid-online.de wrote:
Yes, I _thought_ that was clear. I've to admit that we are currently not using mod_lisp, just the standalone version, but it gives me a cozzy feeling to know that I _could_ get tighter integration once need arises.
Have you actually used mod_lisp for something like that before? I asked because I couldn't really come up with a convincing case where you'd get tighter Apache integration that way. I've done quite a lot of Apache hacking in my pre-Lisp life, but working with something like mod_perl or writing your own modules in C is certainly different from using mod_lisp.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel