On Wed, Apr 9, 2008 at 6:03 PM, Hans Hübner hans@huebner.org wrote:
I spent much of today looking at Hunchentoot and here is my plan for refactoring:
Immediate high level goals:
- Make threading optional on threaded platforms
- Prepare for SERVE-EVENT based buffering
- Clean up and refactor for better hackability
In the longer term, I would like to make more of Hunchentoots data structures into classes that can be subclassed by applications. Requests, sessions and handlers come to mind, all of which currently exist, but they can't easily be extended in an object oriented fashion. Maybe it is good like that and an object oriented framework should be made optional. Also, there should be a logging API.
Hi, I'm a total Lisp (and Hunchentoot) noob so what is coming may well be total nonsense. I took a look at hunchentoot code some time ago, and started some refactoring (I had to abandon it due to a total lack of time) which I would like to comment with you (and maybe help if Iyou decide to try it). The basic idea was to implement Hunchentoot's process-connection as a generic method on a generic connection class. Then we could add layers&transports as simple classes using CLOS :around method dispatch mechanism. For instance we could have an http_connection, mod_lisp, mod_fcgi, https_connection as a top layer class. Then we could have a chunga_stream, flexi_stream class that adds chunked stream capability, etc. Hunchentoot users could create flexible server doing something like (defclass fcgi-server (mod_fcgi chunga-stream flexi-stream)), etc. As I said I don't know if this is sane at all, but I thought I would share my 2 cents anyway.
Cheers, vseguip