[hunchentoot-devel] mod_lisp anyone?
Hi, I'm planning to make some substantial changes to Hunchentoot and it would be helpful if I could remove mod_lisp support in this process. If you are using Hunchentoot with mod_lisp, please let us know. Thanks, Hans
Hans Hübner wrote:
If you are using Hunchentoot with mod_lisp, please let us know.
I'm not using it yet, but a client of mine intends to start using this combination in the future. So if it isn't too much trouble to keep the mod_lisp support, I'd appreciate it. Thanks, Arthur
On Wed, 09 Apr 2008 11:43:53 +0200, "Arthur Lemmens" <alemmens@xs4all.nl> wrote:
I'm not using it yet, but a client of mine intends to start using this combination in the future. So if it isn't too much trouble to keep the mod_lisp support, I'd appreciate it.
What is the reason the client wants to use this combination? FWIW, I'm also in favor of removing the mod_lisp code as it will make Hunchentoot's code base cleaner and easier to maintain. Given that adding mod_lisp to the mix makes your web apps much harder to debug (IMHO of course, YMMV), I'm willing to sacrifice the performance advantages it might have.
Edi wrote:
What is the reason the client wants to use this combination?
As opposed to running Hunchentoot stand-alone, you mean? I don't really know. I guess he likes the cosy feeling of having everything behind Apache.
FWIW, I'm also in favor of removing the mod_lisp code as it will make Hunchentoot's code base cleaner and easier to maintain.
If you and Hans want to get rid of the mod_lisp stuff, don't let me stop you guys. Arthur
2008/4/9, Arthur Lemmens <alemmens@xs4all.nl>:
Edi wrote:
What is the reason the client wants to use this combination?
As opposed to running Hunchentoot stand-alone, you mean? I don't really know. I guess he likes the cosy feeling of having everything behind Apache.
You may be able to convince them that running Hunchentoot in HTTP mode behind Apache configured as transparent proxy is as cosy. Cheers, Hans
On Wed, 09 Apr 2008 16:30:04 +0200, "Arthur Lemmens" <alemmens@xs4all.nl> wrote:
As opposed to running Hunchentoot stand-alone, you mean? I don't really know. I guess he likes the cosy feeling of having everything behind Apache.
You don't need mod_lisp for that. You can put Hunchentoot behind mod_proxy as described in the documentation. That way, you still have a pure Lisp server for testing and debugging, but it is shielded from the Real World[tm] outside by an Apache. I'm doing that all the time. http://weitz.de/hunchentoot/#proxy
Edi wrote:
You don't need mod_lisp for that. You can put Hunchentoot behind mod_proxy as described in the documentation. That way, you still have a pure Lisp server for testing and debugging, but it is shielded from the Real World[tm] outside by an Apache.
I see. Thanks for the info. Arthur
On Wed, 2008-04-09 at 16:50 +0200, Edi Weitz wrote:
On Wed, 09 Apr 2008 16:30:04 +0200, "Arthur Lemmens" <alemmens@xs4all.nl> wrote:
As opposed to running Hunchentoot stand-alone, you mean? I don't really know. I guess he likes the cosy feeling of having everything behind Apache.
You don't need mod_lisp for that. You can put Hunchentoot behind mod_proxy as described in the documentation. That way, you still have a pure Lisp server for testing and debugging, but it is shielded from the Real World[tm] outside by an Apache.
Yes, that' s true iff you need Apache just for that cozzy feelin' But often there's much more built into the Apache server, like Authentication, Authorisation, session handling etc. that needs to be shared with other Apache modules. Sometimes it's possible to tweak Apache in order to use mod_proxy but often that isn't the case. Cheers, Ralf Mattes
On Wed, 09 Apr 2008 17:09:34 +0200, Ralf Mattes <rm@seid-online.de> wrote:
Yes, that' s true iff you need Apache just for that cozzy feelin' But often there's much more built into the Apache server, like Authentication, Authorisation, session handling etc. that needs to be shared with other Apache modules. Sometimes it's possible to tweak Apache in order to use mod_proxy but often that isn't the case.
Was that an argument pro mod_lisp?
On Wed, 2008-04-09 at 17:21 +0200, Edi Weitz wrote:
On Wed, 09 Apr 2008 17:09:34 +0200, Ralf Mattes <rm@seid-online.de> wrote:
Yes, that' s true iff you need Apache just for that cozzy feelin' But often there's much more built into the Apache server, like Authentication, Authorisation, session handling etc. that needs to be shared with other Apache modules. Sometimes it's possible to tweak Apache in order to use mod_proxy but often that isn't the case.
Was that an argument pro mod_lisp?
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. Cheers, RalfD
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.
In my case, as I'm developing CLAW, using mod_proxy instead of mod_lisp shouldn't be a problem. On Wed, Apr 9, 2008 at 5:34 PM, Edi Weitz <edi@agharta.de> wrote:
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
It should also be nice if you consider to adapt the session realm logic (if it is the case) that I've adopted overriding hunchentoot in CLAW, so that I can remove the overriding file from my project. On Wed, Apr 9, 2008 at 7:06 PM, Andrea Chiumenti <kiuma72@gmail.com> wrote:
In my case, as I'm developing CLAW, using mod_proxy instead of mod_lisp shouldn't be a problem.
On Wed, Apr 9, 2008 at 5:34 PM, Edi Weitz <edi@agharta.de> wrote:
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
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
On Thu, 2008-04-10 at 13:54 +0200, Hans Hübner 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?
As I wrote in my last mail, I'm not currently using it. I kept mod_lisp as an option in case I need tighter Apache integration. I'm currently a little, erm, tight on time so I can't come up with elaborate examples now. One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ... It might be possible to do this with mod_proxy as well, but I think it would be cneptually cleaner to view the Lisp process just as yet another content provider module.
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.
+1 from me.
It would be helpful if Robert and/or Andrea could write down how session support needs to be enhanced.
Thanks, Hans
Thanks, Hans
Cheers, RalfD and thank's for working on hunch
On Thu, 10 Apr 2008 14:13:24 +0200, Ralf Mattes <rm@seid-online.de> wrote:
As I wrote in my last mail, I'm not currently using it. I kept mod_lisp as an option in case I need tighter Apache integration. I'm currently a little, erm, tight on time so I can't come up with elaborate examples now. One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ...
It might be possible to do this with mod_proxy as well, but I think it would be cneptually cleaner to view the Lisp process just as yet another content provider module.
I haven't worked with Apache 2.x filters yet, so I can't comment on this example. (But I think you're right and it's a reasonable example.) Filters were about the only thing that came to mind when I tried to come up with a reason to use mod_lisp because the standard (1.x) way of writing and combining modules as described in the nice eagle book doesn't really fit with how mod_lisp works. So, yes, your case might be a good reason to use mod_lisp. Whether it is a good reason to have mod_lisp support in Hunchentoot I'm not so sure. Speaking of being conceptually clean, Hunchentoot has evolved over the years and now is (or aims to be) a fully-fledged stand-alone Lisp web server. 90% of its code base is probably totally useless if you're just trying to write a content provider module to hook into Apache. Wouldn't it make more sense to use something like cl-modlisp for this?
On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ...
mod_xslt2 seems pretty limited. From: http://www.mod-xslt2.com/doc/manual.xml?sect=5 5.1.9 Increasing performance <snip/> Since mod-xslt2 is part of apache itself, a pipe is impossible to use, unless we fork apache one more time, slowing things down. The simplest approach has thus been used: creating a temporary file, let other modules write the replies in there, and then parse the temporary file. However, by using temporary files, we hit I/O performance issues. <snip/> plus, it is only XSL 1.0. There was someone working on an XSL processor in lisp, but I don't think it is ready yet (forgot the name). Java is currently the best environment if you have to deal with XSL transformations server side. If you are using XSL 1.0 only, you could just do the transformation on the client -- pretty much all browser now support XSL 1.0. best, -Rob
Thanks, all! I think removing mod_lisp support is the right thing to do for the moment, as there is enough other work. -Hans 2008/4/10, Robert Koberg <rob@koberg.com>:
On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ...
mod_xslt2 seems pretty limited. From:
http://www.mod-xslt2.com/doc/manual.xml?sect=5
5.1.9 Increasing performance <snip/>
Since mod-xslt2 is part of apache itself, a pipe is impossible to use, unless we fork apache one more time, slowing things down.
The simplest approach has thus been used: creating a temporary file, let other modules write the replies in there, and then parse the temporary file. However, by using temporary files, we hit I/O performance issues. <snip/>
plus, it is only XSL 1.0. There was someone working on an XSL processor in lisp, but I don't think it is ready yet (forgot the name).
Java is currently the best environment if you have to deal with XSL transformations server side. If you are using XSL 1.0 only, you could just do the transformation on the client -- pretty much all browser now support XSL 1.0.
best, -Rob
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Thu, 2008-04-10 at 08:59 -0400, Robert Koberg wrote:
On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ...
mod_xslt2 seems pretty limited. From:
In case you responded to my message: did I ever mention mod-xslt2? We use our own xslt transforming module using Daniel's excellent libxslt (unfortunately the module is named mod_xslt, but it's actually much older than the well known modules :) When I hacked the first version it was meant as a joke to make fun of the java software used back then. I can't really comment on mod-xslt2 since I only use it on a rather seldom exposed area of the website but I don't think it's especially slow. My only critique would be that it suffers from a severe "second implementation syndrome" - there _seems_ to be quite a lot of premature (?) optimization and feeping keaturism IMHO. Our little module doesn't even bother to cache the compiled stylesheet - every request reads, parses and compiles the needed stylesheets (and boy do they overuse includes and imports :-) and the transforms the content. So far we seldom had performance problems, even so the site runs on stock server hardware.
5.1.9 Increasing performance <snip/>
Since mod-xslt2 is part of apache itself, a pipe is impossible to use, unless we fork apache one more time, slowing things down.
The simplest approach has thus been used: creating a temporary file, let other modules write the replies in there, and then parse the temporary file. However, by using temporary files, we hit I/O performance issues. <snip/>
Where's my babelfish?
plus, it is only XSL 1.0. There was someone working on an XSL processor in lisp, but I don't think it is ready yet (forgot the name).
Yeah. Only XSLT 1. IMHO that's a feature, not a bug. XSLT 1 had a very clear operational model (by accident, i fear, they seem to have inherited it from the DSSSL past) that should be near and dear to us Schemers^H^H Lispers - purely functional without assignment.
Java is currently the best environment if you have to deal with XSL transformations server side. If you are using XSL 1.0 only, you could just do the transformation on the client -- pretty much all browser now support XSL 1.0.
Last time we tested that wasn't a convincing option since that required the transfer of stylesheets (since the site uses a rather modular stylesheet setup that resulted in a noticeable increase in server load). Cheers, RalfD
best, -Rob
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
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
2008/4/9, Ralf Mattes <rm@seid-online.de>:
But often there's much more built into the Apache server, like Authentication, Authorisation, session handling etc. that needs to be shared with other Apache modules. Sometimes it's possible to tweak Apache in order to use mod_proxy but often that isn't the case.
This is a good reason not to abandon mod_lisp support. -Hans
Hello Hans, On 9 apr 2008, at 11:39, Hans Hübner wrote:
I'm planning to make some substantial changes to Hunchentoot and it would be helpful if I could remove mod_lisp support in this process.
Interesting; what are these substantial changes?
If you are using Hunchentoot with mod_lisp, please let us know.
We (Streamtech) are using it in some relatively large web applications; although moving to an infrastructure without mod_lisp is possible, doing so would take quite some effort that we're not necessarily willing to take. Unless the substantial changes make up for it, of course ;) -Arjan Wekking, Streamtech bv
On Wed, Apr 09, 2008 at 12:07:55PM +0200, Edi Weitz wrote:
On Wed, 9 Apr 2008 11:57:12 +0200, Arjan Wekking <arjan@streamtech.nl> wrote:
We (Streamtech) are using it in some relatively large web applications
Like in Arthur's case, I'd be interested in why you decided to go with mod_lisp. Just curious... :)
I don't know about Arjan, but I use mod_lisp because my tbnl site used it and I didn't feel like setting up anything new when I upgraded to hunchentoot. I'm not against using a proxy, but, you know, inertia... On the other hand, inertia is also against me ever actually *upgrading* hunchentoot, now that I have it installed. The new features would have to be *very* compelling. :) Zach
On 9 apr 2008, at 12:07, Edi Weitz wrote:
On Wed, 9 Apr 2008 11:57:12 +0200, Arjan Wekking <arjan@streamtech.nl> wrote:
We (Streamtech) are using it in some relatively large web applications
Like in Arthur's case, I'd be interested in why you decided to go with mod_lisp. Just curious... :)
Well, it's partially historical (we moved some parts of the application from UCW to hunchentoot, keeping the mod_lisp set up as it was) and to a certain degree because of performance (we've been doing an average 6 requests per second 24/7 on the main part of our application). Keeping Apache in front of Lisp has turned out to be a very pleasant setup for both performance (we serve quite some static files as well) and run-time management (to configure HTTP processing details, dealing with name bases virtual hosting and moving apps around without any downtime). We know this works just as well when running behind mod_proxy (as Zach mentioned) so we're not really depending on mod_lisp for that. So, to sum things up; we know mod_lisp is a very thin layer compared to just proxying HTTP requests and we've been thinking of taking it out on some occasions (the behaviour it displays when restarting a Lisp without restarting Apache has been an issue now and then) so if mod_lisp support was dropped we would eventually change to a mod_proxy set up when we want to upgrade Hunchentoot, I guess. -Arjan Wekking, Streamtech bv
2008/4/9, Arjan Wekking <arjan@streamtech.nl>:
On 9 apr 2008, at 11:39, Hans Hübner wrote:
I'm planning to make some substantial changes to Hunchentoot and it would be helpful if I could remove mod_lisp support in this process.
Interesting; what are these substantial changes?
I want to change Hunchentoot so that the threading model for request execution is a configuration parameter, not a function of what the Lisp implementation provides. For my primary application, I currently need a single threaded model where one thread both listens for requests and executes them. In the future, I may need to support a thread pool. I would also like to factor the SSL specific functionality into a separate server class. Removing the mod_lisp code would make overall refactoring easier, as the mod_lisp decisions are spread all over the code. Also, it is harder to test changes if one has to test both with mod_lisp and http. Presently I am primarily looking for ways to simplify the code in order to make it easier to change and extend.
If you are using Hunchentoot with mod_lisp, please let us know.
We (Streamtech) are using it in some relatively large web applications; although moving to an infrastructure without mod_lisp is possible, doing so would take quite some effort that we're not necessarily willing to take. Unless the substantial changes make up for it, of course ;)
Are there any features that you are really looking for? -Hans
On Wed, 9 Apr 2008 12:11:45 +0200, "Hans Hübner" <hans@huebner.org> wrote:
Removing the mod_lisp code would make overall refactoring easier, as the mod_lisp decisions are spread all over the code. [...] Presently I am primarily looking for ways to simplify the code in order to make it easier to change and extend.
Which is something I heartily support. There are a lot of things I'd like to change (but don't have the time for right now) and whenever I look at Hunchentoot's code for more than a few seconds I'm driven to tears by how ugly it is. Lots of this is due to it growing "organically" from being a thin CMUCL layer on top of mod_lisp (ca. 2001/2002) to what it is now, and some of the "design" decisions which probably should be revisited can only be revoked if we're willing to sacrifice a bit of backwards compatibility here and there.
On Wed, Apr 9, 2008 at 10:11 AM, Hans Hübner <hans@huebner.org> wrote:
Are there any features that you are really looking for?
How hard would it be to make sessions work independently of hunchentoot? I'd like (or rather Kenny would like) to make my openAIR stuff work with aserve. Aserve does have webactions but it seems to involve more than just sessions. They have a concept of "managed pages" which doesn't really fit with the way I've done things so far. I made a half-hearted attempt at just copying sessions.lisp and specials.lisp into my own project but it seemed like if I was actually going to make it work, I'd end up with all the same dependencies as hunch anyway so what would be the point. I also remember thinking it might be nice to have some of the request accessors be methods instead of functions. Would that be expensive in terms of performance? It would mean I could code my project to hunch's interface and add defmethods to handle aserve requests differently. -- Andy
On Wed, 9 Apr 2008 10:49:56 +0000, "Andy Chambers" <achambers.home@googlemail.com> wrote:
How hard would it be to make sessions work independently of hunchentoot?
Depends if you want cookie-less sessions or not. But in both cases it shouldn't be /too/ hard, I'd say.
I also remember thinking it might be nice to have some of the request accessors be methods instead of functions.
That's on my todo list as well. But don't hold your breath.
Would that be expensive in terms of performance?
I don't care.
2008/4/9, Andy Chambers <achambers.home@googlemail.com>:
How hard would it be to make sessions work independently of hunchentoot? I'd like (or rather Kenny would like) to make my openAIR stuff work with aserve. Aserve does have webactions but it seems to involve more than just sessions. They have a concept of "managed pages" which doesn't really fit with the way I've done things so far.
I made a half-hearted attempt at just copying sessions.lisp and specials.lisp into my own project but it seemed like if I was actually going to make it work, I'd end up with all the same dependencies as hunch anyway so what would be the point.
I'd recommend that you implement your own session management scheme based on cookies - It is not a hard thing to do and will propably be easier than to factor out the sessions specific parts of Hunchentoot into something that could be reused with Aserve. I don't know anything about your target audience, but if you don't try to support people who have switched off Cookies, handling sessions is rather easy.
I also remember thinking it might be nice to have some of the request accessors be methods instead of functions. Would that be expensive in terms of performance? It would mean I could code my project to hunch's interface and add defmethods to handle aserve requests differently.
Edi and I discussed that earlier on and it is on the list of things that we would like to have. The tradeoff is API simplicity. Currently, the the request argument is optional in all accessors, thus we can't easily make them be a generic function. -Hans
On Wed, Apr 9, 2008 at 12:04 PM, Hans Hübner <hans@huebner.org> wrote:
2008/4/9, Andy Chambers <achambers.home@googlemail.com>:
How hard would it be to make sessions work independently of hunchentoot? I'd like (or rather Kenny would like) to make my openAIR stuff work with aserve. Aserve does have webactions but it seems to involve more than just sessions. They have a concept of "managed pages" which doesn't really fit with the way I've done things so far.
I made a half-hearted attempt at just copying sessions.lisp and specials.lisp into my own project but it seemed like if I was actually going to make it work, I'd end up with all the same dependencies as hunch anyway so what would be the point.
I'd recommend that you implement your own session management scheme based on cookies - It is not a hard thing to do and will propably be easier than to factor out the sessions specific parts of Hunchentoot into something that could be reused with Aserve. I don't know anything about your target audience, but if you don't try to support people who have switched off Cookies, handling sessions is rather easy.
The current sessions aren't suited to all cases, anyway; in particular, they're not suitable for a system with multiple frontend machines unless you're binding users to a specific machine on login (which carries its own problems with it). Rob.
If I understand what you're saying, the openAIR stuff currently works on hunchentoot and there is a desire to see it ported to aserve. Just curious, but what is the motivation for wanting to use aserve? Is it a performance issue? installed base? etc... thanks, Cyrus On Apr 9, 2008, at 3:49 AM, Andy Chambers wrote:
On Wed, Apr 9, 2008 at 10:11 AM, Hans Hübner <hans@huebner.org> wrote:
Are there any features that you are really looking for?
How hard would it be to make sessions work independently of hunchentoot? I'd like (or rather Kenny would like) to make my openAIR stuff work with aserve. Aserve does have webactions but it seems to involve more than just sessions. They have a concept of "managed pages" which doesn't really fit with the way I've done things so far.
I made a half-hearted attempt at just copying sessions.lisp and specials.lisp into my own project but it seemed like if I was actually going to make it work, I'd end up with all the same dependencies as hunch anyway so what would be the point.
I also remember thinking it might be nice to have some of the request accessors be methods instead of functions. Would that be expensive in terms of performance? It would mean I could code my project to hunch's interface and add defmethods to handle aserve requests differently.
-- Andy _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
On Wed, 9 Apr 2008 08:06:00 -0700, Cyrus Harmon <ch-tbnl@bobobeach.com> wrote:
If I understand what you're saying, the openAIR stuff currently works on hunchentoot and there is a desire to see it ported to aserve. Just curious, but what is the motivation for wanting to use aserve?
Probably Kenny's fondness for AllegroCL... :)
Hans Hübner wrote:
Hi,
I'm planning to make some substantial changes to Hunchentoot and it would be helpful if I could remove mod_lisp support in this process.
If you are using Hunchentoot with mod_lisp, please let us know.
Thanks, Hans
I hope I'm not too late to provide input on this question - I currently have six servers running behind mod_lisp. It would be a lot of unwelcome work to convert these to mod_proxy. --Jeff
Hey, I shifted to mod_proxy when I shifted from TBNL to Hunchentoot. :) We have run it under heavy load at www.cleartrip.com and it works like a charm. There are advantages of running behind Apache(s) and especially so as independent proxied application servers. It's also a cleaner design IMHO. Best of luck & thanks! quasi On 09-Apr-08, at 3:09 PM, Hans Hübner wrote:
Hi,
I'm planning to make some substantial changes to Hunchentoot and it would be helpful if I could remove mod_lisp support in this process.
If you are using Hunchentoot with mod_lisp, please let us know.
Thanks, Hans _______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
participants (13)
-
Abhijit Rao -
Andrea Chiumenti -
Andy Chambers -
Arjan Wekking -
Arthur Lemmens -
Cyrus Harmon -
Edi Weitz -
Hans Hübner -
Jeff Cunningham -
Ralf Mattes -
Robert Koberg -
Robert Synnott -
Zach Beane