Quoth Hans Hübner hans.huebner@gmail.com:
On Thu, Sep 22, 2011 at 8:48 AM, Sebastian Tennant sebyte@smolny.plus.com wrote:
At one point I considered hunchentoot-vhost but decided against it. It seemed quite complex (at least to me).
I am using squid as a frontend to pretty much the same effect (I use it for SSL processing, too).
Cool. I've never tried squid but I'll definitely have a look at it now, if I ever find time!
Sadly, I have not made progress regarding the changing the architecture of Hunchentoot in ways that would decouple request handling from accepting. What would really be needed is a request routing concept that is orthogonal to request handling. Virtual host handling would then become part of the request routing.
IMHO, the fact that there's only a single *dispatch-table* is 'the big thing' that needs changing.
Adding a dispatch-table slot (with default value *dispatch-table*) to the acceptor class would probably suffice, though it's probably not that simple.
My workaround uses the acceptor :name slot to store the name of the dispatch table for that acceptor) and I then define a modified request dispatcher function that binds *dispatch-table* accordingly:
;;; per-acceptor dispatch tables (defun choosing-list-request-dispatcher (request) (let ((*dispatch-table* (eval (acceptor-name *acceptor*)))) (loop for dispatcher in *dispatch-table* for action = (funcall dispatcher request) when action return (funcall action) finally (setf (return-code *reply*) +http-not-found+))))
;;; initalise dispatch tables (defvar *exmaple-dot-com-dispatch-table* '(default-dispatcher)) (defvar *foobar-dot-org-dispatch-table* '(default-dispatcher))
;;; acceptors (defvar example-dot-com (make-instance 'acceptor :name '*exmaple-dot-com-dispatch-table* :address "127.0.0.1" :port 49154 :request-dispatcher 'choosing-list-request-dispatcher))
(defvar foobar-dot-org (make-instance 'acceptor :name '*foobar-dot-org-dispatch-table* :address "127.0.0.1" :port 49155 :request-dispatcher 'choosing-list-request-dispatcher))
Even though easy handlers are currently defined as acceptor subclass, I do not think that this is the best way to implement a framework on top of Hunchentoot. I refactored easy handlers that way because it was the quickest way to make them optional, as I wanted to get the easy handler code out of the common code path used for all handlers.
I found easy handlers too difficult to use :) so I've never used them and therefore can't really comment, although getting their code out of the common code path sounds like a sensible thing to be doing.
If you [...] require architectural microchanges within the current class layout, I'll gladly review pull requests
Noted.
on github and also make them part of the main repository.
Sorry... isn't 'hunchentoot on github' and 'the main repository' one and the same thing?
I am also open to larger efforts if anyone has the time to do that. This can happen on a github fork first and moved to the edicl repository once there is sufficient interest and movement.
Noted.
For the long-promised, still-undated upcoming release of Hunchentoot, my focus is to stabilize the feature set that exists right now.
Might it not be a good idea to make an announcement with subject line 'Hunchentoot frozen pending imminent release - bugfixes welcome' or words to that effect?
Seb