[hunchentoot-devel] Re: Refactoring work plan

[Edi Weitz]

On Wed, 9 Apr 2008 18:03:11 +0200, "Hans Hübner" <hans at huebner.org> wrote:

> Immediate high level goals:
>
> - Make threading optional on threaded platforms
> - Prepare for SERVE-EVENT based buffering
> - Clean up and refactor for better hackability

I agree with all of these.

> 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.

This was on my todo list anyway.  I'm currently thinking that (for
example) REMOTE-ADDR should be a plain function with one optional
argument which calls a generic function REMOTE-ADDR% (or however it's
named) with one required argument which is also exported.  That would
look a bit bloated initially, but it'd be backwards-compatible and
convenient for most users while those who want/need it, can go "one
level down" and specialize the generic functions.

> Also, there should be a logging API.

I haven't really looked at the available logging libs yet.  Would it
make sense to use one of those?  The current implementation certainly
has a couple of flaws.

> - Use USOCKET instead of private compatibility library.  Currently,
> threading and socket I/O is intermixed because COMM:START-UP-SERVER
> from Lispworks is emulated by all platforms.  Also, timeouts will be
> provided through USOCKET.

Hunchentoot spent the first year of its life as a LispWork-only
library... :)

> - Use BORDEAUX-THREADS for threading.  Currently, threads are
> assumed to be processes as in Lispworks.  I particularily dislike
> the use of PROCESS-KILL to shutdown the server.

That's the documented way to stop a server on LW:

  http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-61.htm

> - Clean up and refactor to reduce the number of special variables

Yep.

> - Move platform specific code into subdirectory

Yep.

> - Once we have decided whether we want to keep mod_lisp: Refactor so
> that mod_lisp specific code is isolated or remove it altogether.

Maybe it's sufficient if you provide support to implement a mod_lisp
"backend" without actually doing it yourself.  If there's enough
demand, then someone will (hopefully) add the necessary code.

> If you think anything of this is terrible and/or a bad idea, speak
> up.

Sounds great to me.  Except that after all of this, Hunchentoot will
be your library and not mine anymore.  But that's also fine with
me... :)