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

[Hans Hübner]

On Thu, Sep 22, 2011 at 10:03 PM, Sebastian Tennant
<sebyte at smolny.plus.com> wrote:
> Quoth Hans Hübner <hans.huebner at gmail.com>:

> IMHO, the fact that there's only a single *dispatch-table* is 'the big thing'
> that needs changing.

> Adding a dispatch-table slot (with default value *dispatch-table*) to the
> acceptor class would probably suffice, though it's probably not that simple.

I can agree to that, but subclassing acceptors is not really modular
(i.e. it is as right or wrong as the easy-acceptor subclass).  I think
it would make sense to have a dispatcher class.  Every acceptor would
have an dispatchers slot that contained a list of dispatcher instances
which would be consulted, one after another, to route the request.

That way, it would be possible to share dispatcher instances between
acceptors.  For example, a web site could have a dispatcher for the
anonymous, sessionless front-end functionality that would be used by
the http port.  The same dispatcher instance would be on the
dispatchers list of the https acceptor, and in addition there would be
a dispatcher instance for the, say, content management system on that
acceptors dispatchers list.  Also, the dispatcher class would be
responsible for implementing virtual hosts, i.e. there would be one
dispatcher for every virtual host supported.

Now this sounds nice and easy, but it adds to the number of instances
that need to be created in order to start Hunchentoot.  Starting
Hunchentoot in any but the most basic standard configurations is
already a chore, requiring various make-instance invocations and
initargs.  If we move forward in this direction, I think we need to
improve how Hunchentoot is configured and started, too.  Basically,
this would be a declarative syntax that contained the various classes
and instiation arguments.

>> on github and also make them part of the main repository.
>
> Sorry... isn't 'hunchentoot on github' and 'the main repository' one and the
> same thing?

"on github" means "in any fork", "the main repository" means edicl/hunchentoot.

> Might it not be a good idea to make an announcement with subject line
> 'Hunchentoot frozen pending imminent release - bugfixes welcome' or words to
> that effect?

Yes.  As soon as the freeze point is reached, that will happen.
Before that, here is what I'd like to do:

- Conceptionalize dispatching (in the way described above or a
different modular way)
- Implement declarative configuration
- Integrate Hunchensocket
- Set up default file system with documentation and nice-looking error pages

Anything else?  Let me know.  In order for this to actually happen,
discussion and collaboration is needed.

-Hans