[hunchentoot-devel] socket-connector and ssl-socket-connector?

[Sebastian Tennant]

Quoth Hans Hübner <hans.huebner at gmail.com>:
> On Thu, Sep 22, 2011 at 8:48 AM, Sebastian Tennant
> <sebyte at 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
-- 
Emacs' AlsaPlayer - Music Without Jolts
Lightweight, full-featured and mindful of your idyllic happiness.
http://home.gna.org/eap