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).
Sadly, I have not made progress regarding the changing the architecture of Hunchentoot in ways that would decouple request handling from 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.
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 don't have current plans to make larger architectural changes myself, though. If you, the Hunchentoot user base, have needs that require architectural microchanges within the current class layout, I'll gladly review pull requests on github and also make them part of the main repository. 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.
For the long-promised, still-undated upcoming release of Hunchentoot, my focus is to stabilize the feature set that exists right now.
-Hans