[hunchentoot-devel] recent-ish hunchentoot changes

[Hans Hübner]

Hi Cyrus,

thanks for your feedback!

On Fri, Apr 8, 2011 at 2:00 AM, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:
> 1. This is still only in the svn (and various mirrors) versions, not yet in a released version, right? Any idea when we should expect a release with these changes?

No date has been set for a release, and I'd really like to wait with
this until all known major problems are gone.

> 2. default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing?

Right.

> 3. is the "new" way to handle requests to subclass acceptor, as easy-acceptor does? How is this supposed to play with the ssl-acceptor? Should we define regular (non-ssl) acceptors and ssl-acceptors for our code? I think of http vs. https as more of a transport issue than an application logic issue. It seems a little odd to be using subclassing, along one axis, for http vs. https and for application-logic, along another axis. Am I missing something?

You are right, and that problem has bothered me for a bit.  What I
really want to do is fold SSL into Hunchentoot in a way that does not
collide with the interface that is being exposed for general
application program.  I've not thought through this thoroughly, but
I'm thinking that a new REQUEST-PROCESSOR class is needed that does
the actual request handling and is separate from ACCEPTOR, which does
the connection management.  Multiple ACCEPTOR instances could then
share one REQUEST-PROCESSOR, or - in the virtual host case - there
could be a M:N relationship between instances of the two classes.

REQUEST-PROCESSOR would then be the class that applications would
often subclass, whereas ACCEPTOR would rarely need change.

Does that generally make sense to you?

-Hans