[hunchentoot-devel] socket-connector and ssl-socket-connector?

Hans Hübner hans.huebner at gmail.com
Wed Apr 20 08:01:11 UTC 2011


On Mon, Apr 18, 2011 at 4:56 PM, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:
> 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.

At this point, I'd prefer not to add new classes unless they really
fulfill a need.  I have been pondering whether/if Hunchentoot can be
converted to an event oriented web server somehow, but that would
require much more than separating out the connector functionality.
The real issue, I think, is that the underlying streams are not event
oriented.  The flow of control would need to be basically reverted,
and that is something that I'm not up to doing.  Maybe using
Hunchentoot as a start is a bad idea anyway.  Anyway, I'd like to keep
things as simple as possible.

> 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.

The task of a SERVER class would be to read a configuration
specification and instantiate the required objects that make up the
server.  In the simple case, this would be one ACCEPTOR, one
TASKMASTER and one REQUEST-HANDLER.  In more complex cases, more
ACCEPTOR instances would be present (to listen on multiple ports) or
more REQUEST-HANDLERS would exist to, say, serve multiple virtual
hosts.

I will need a few more weeks until I can really put effort into
reviewing the patches and implement the new mechanisms.  I also hope
that the SSL problems are sorted out until then, as the upcoming
release should certainly support SSL.

-Hans




More information about the Tbnl-devel mailing list