[hunchentoot-devel] global dispatch-table
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.
participants (2)
-
Cyrus Harmon -
Edi Weitz