Hi Cyrus,
thanks for your feedback!
On Fri, Apr 8, 2011 at 2:00 AM, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
- 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.
- default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing?
Right.
- 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