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

[Cyrus Harmon]

Hi Hans and the rest of the hunchentoot folks,

Sorry for the silence on this, but I'm curious to see if anything has happened in the last few months that changes things. The main problem I had with the hunchentoot changes from late last year/early this year where that my hunchentoot-vhost no long worked, and it wasn't clear how to cleanly make things work. I thought the socket-connector and dispatcher patches solved the problem in an appropriate manner.

I've been away from this for quite some time, but I, once again, find myself needing to run multiple, in apache parlance, virtual hosts, on a single pair or 80 and 443 ports. I'm happy to abandon my hunchentoot-vhost approach if there's a better option, but I'd hate to have to recode that stuff for no good reason. Any suggestions?

thanks,

Cyrus
 
On Apr 20, 2011, at 1:01 AM, Hans Hübner wrote:

> 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
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel