[hunchentoot-devel] Re: Current development

[Lars Rune Nøstdal]

Edi Weitz wrote:
> On Sat, 14 Jun 2008 07:21:05 +0200, Lars Rune Nøstdal <larsnostdal at 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.

-- 
Lars Rune Nøstdal
http://nostdal.org/