[hunchentoot-devel] Refactoring work plan

[vseguip at gmail.com]

On Wed, Apr 9, 2008 at 6:03 PM, Hans Hübner <hans at 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