Edi Weitz wrote:
On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune Nøstdal larsnostdal@gmail.com wrote:
A major problem is global variables.
As you already mentioned, this will be partly addressed by upcoming changes. Still, I'd be interested in how far this is really a "major problem" when you try to implement certain things. You aren't forced to use the special variables, are you?
No, I guess not -- maybe not. It starts with a socket/stream at the connection-manager end, and functions seem to accept &optional (reply *reply*) etc. .. so I can build on that from the lowest levels and up, I think.
I'll give this a new try a bit later and go about it a bit slower and build something from the ground up instead. I figured I could hack this together quickly with the parts that where there already by moving them around and splitting them up a bit, but maybe that's not such a good idea currently. It just gets more complicated that way I think.
..I should wait a bit and see what happens though..
I still have a feeling the global variables should be removed or, that is, gathered together into a "single blob" so the whole concept of a request-response cycle (round-trip) can be passed around easily if the user really needs to do this.
I know global vars aren't "dangerous" in Lisp like in other languages when they are bound (LET) within a single thread where the execution path is predefined or stays within a single thread; that's not what I mean =) .. but in this case the bindings or data needs to be accessed from multiple threads (or well, moved to a new thread) as the cycle "walks forward".
But, OK, never mind .. globals vars are being addressed - and/or I can just not used them for my stuff; right. It will work out.
Also, this means handling of a round-trip cycle cannot be hardcoded into a single function/method or into a single path of execution (a single thread). Using things like UNWIND-PROTECT makes the path of execution static; "when thread ends close the stream" (but we, well I, don't want this!).
The goal of the current development obviously is to make Hunchentoot more flexible and at the same time to give its users more rope to hang themselves. In the end, it will still be a web server, though, with an eye on simplicity and backwards compatibility, it won't become an all singing and dancing General Problem Solver. I hope you won't be disappointed.
Yeah, I don't think I'll be disappointed but it would be great not having to write huge parts from scratch like mentioned above even though it would actually be possible to do so.
If things are split up and work more on their own not depending on different context bits (global variables, let-bindings etc.) at the same time this will enable code-bits to be shared between multiple server backends, modules or connection-managers, I think/hope.
(Just out of curiosity, are there general purpose web servers out there where one single request is not handled within one thread/process? I'm aware that Apache for example has a pretty sophisticated model of providing different ways of hooking into the request handling architecture. Still, I think, the thread that accepts the request will always be the one which is in charge of sending the reply and cleaning up, or am I wrong?)
The thread cannot wait around for the server to have anything to send as a response; it will not scale in any Lisp I know of.