Hi Hans,
Well, that's a good question. I think the idea is that someone could both extend ACCEPTOR (and TASKMASTER) (a fancy epoll-using ACCEPTOR perhaps?) and still have said ACCEPTOR-subclass useable with SSL without subclassing. I like the idea of composing in the SSL-based socket functionality at runtime without subclassing -- at least I liked it enough to try out the approach. I'm not certain this is the best approach, but it looked reasonable enough to try it out and it seems to work. If the consensus is that this isn't a good approach, I can live with that.
As for the DISPATCHER / REQUEST-HANDLER, sure I'm happy to see it renamed to REQUEST-HANDLER.
I think a SERVER class that holds one or more acceptors would be a fine thing. I seem to end up coding something like that by hand when I need it (the ability to do so should remain, of course) but it would be nice to have a standard way to wrap those servers as I think that's a pretty common use case.
And, yes, I think a way of associating multiple request handlers with acceptors would be a good thing. I guess the question is should the ACCEPTOR do that or should we delegate to something like a DISPATCHER which would call each REQUEST-HANDLER?
Thanks for taking a look at my patches.
Cyrus
On Apr 17, 2011, at 10:48 PM, Hans Hübner wrote:
Hi Cyrus,
without having looked at your patches thoroughly, a question: Why does it make sense to have an extra socket-connector class? I'd put the connection type specific functionality into acceptor, and just add the dispatcher class that you've proposed, although I would like to call it request-handler. It may make sense to add an umbrella "server" class that holds one or more acceptors.
The goal that I see is:
- It should be possible to have one server serve multiple ports, e.g.
SSL and non-SLL, but share one object that the application can attach things to.
- It should be possible to have multiple request handler instances.
They should be attached to a server and be tried in a well-defined order to handle incoming requests. Hunchentoot would provide two request handler classes, easy-handlers and file-handlers.
Thoughts? -Hans
On Mon, Apr 18, 2011 at 12:13 AM, Cyrus Harmon ch-tbnl@bobobeach.com wrote:
I've been playing around with some changes to ACCEPTOR and friends that introduce the new classes SOCKET-CONNECTOR and SSL-SOCKET-CONNECTOR. The purpose of these changes are to take the specialized socket handling behavior out of the acceptor and into another class, such that subclassing acceptor isn't required to, say, use SSL streams.
As a motivating example, consider the following:
(hunchentoot:start (make-instance 'hunchentoot:easy-acceptor :port 4243 :socket-connector (make-instance 'hunchentoot::ssl-socket-connector :ssl-certificate-file (asdf:system-relative-pathname :hunchentoot "ssl/certificate.pem") :ssl-privatekey-file (asdf:system-relative-pathname :hunchentoot "ssl/key.pem"))))
(hunchentoot:define-easy-handler (say-yo :uri "/yo") (name) (setf (hunchentoot:content-type*) "text/plain") (format nil "Hey~@[ ~A~]!" name))
Without these changes, one would have to subclass both easy-acceptor and ssl-acceptor in order to have an SSL-using easy acceptor. Comments/suggestions greatly appreciated.
The changes can be found in the git repo at:
https://github.com/slyrus/hunchentoot/tree/socket-connector
and in the attached patch.
Cyrus
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel