On Thu, Sep 22, 2011 at 10:03 PM, Sebastian Tennant sebyte@smolny.plus.com wrote:
Quoth Hans Hübner hans.huebner@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