So, I see that way requests are handled has changed a bit in the last couple months. This leads me to a couple questions:
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?
2. default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing?
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?
In case anyone's curious, I'm trying to bring my hunchentoot-vhost forward to work with the new hunchentoot, and it's requiring a bit of a rethinking of how I handle requests. I'm happy to make a hunchentoot-vhost-acceptor, if that's the way to go, but I'm a little less thrilled about having to make a hunchentoot-vhost-ssl-acceptor too.
I think the new design generally looks nice, but it's still taking some getting used to.
thanks!
Cyrus
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
On Apr 7, 2011, at 9:16 PM, Hans Hübner wrote:
Hi Cyrus,
thanks for your feedback!
By all means. Thanks to you (and Edi et al.) for continuing to improve hunchentoot!
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.
Fair enough, but there can be a bit of a chicken-and-egg problem here in that folks will be reluctant to adopt the new ways unless they see the train approaching quickly.
- default-dispatcher and *default-handler* seem to have gone away, right? and *dispatch-table* is now an easy-handler-only thing?
Right.
Ok, I think this is good. Things like *default-foo* occasionally suggest that there might be a way to better restructure the code such that defaults aren't hardcoded in special variables like that -- and I think that may be the case here.
- 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?
Not only does it make sense to me, it echoes what I was thinking about a couple of days ago, after I sent my previous message. I think something like a request-processor (I was thinking of request-handler, but that's the same thing) might be in order. I'm working on thinking through how this might work and will follow up with another email in the next few days.
Thanks for taking the time to discuss these issues.
Cyrus
-Hans
-
Cyrus Harmon -
Hans Hübner