What's the rationale behind a global dispatch table? It seems like it might be nicer to have a per-server dispatch table. I can't imagine that there would be a good reason not have access to the server object when accessing *dispatch-table*, although as currently structured process-request should probably take an additional argument for the server.
Thanks,
Cyrus
On Mon, 4 Dec 2006 12:42:08 -0800, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
What's the rationale behind a global dispatch table? It seems like it might be nicer to have a per-server dispatch table. I can't imagine that there would be a good reason not have access to the server object when accessing *dispatch-table*, although as currently structured process-request should probably take an additional argument for the server.
The rationale is that it's a leftover from the times when Hunchentoot was (based on) TBNL and TBNL was a single-server library. Have you seen *META-DISPATCHER*?
http://weitz.de/hunchentoot/#*meta-dispatcher*
Note that you always have access to the server object via the *SERVER* variable.
Cheers, Edi.
On Mon, 04 Dec 2006 21:51:54 +0100, Edi Weitz edi@agharta.de wrote:
The rationale is that it's a leftover from the times when Hunchentoot was (based on) TBNL and TBNL was a single-server library.
Let me add that with hindsight I think this is the right decision. Yes, with Hunchentoot you /can/ have multiple servers, but I don't think it makes sense to view Hunchentoot as a content-agnostic workhorse like Apache. I prefer to view it as a building block for creating application servers, and if you have more than one server in the same image, I think it is very likely that what these servers serve will be related. Thus, a global dispatch table makes sense to me. If it doesn't make sense to you, there's *META-DISPATCHER*, as I said.
Cheers, Edi.
-
Cyrus Harmon -
Edi Weitz