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