On Wed, 9 Apr 2008 18:03:11 +0200, "Hans Hübner" hans@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... :)