[hunchentoot-devel] Refactoring work plan
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. Short term hacking plan: - 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. - 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. - Clean up and refactor to reduce the number of special variables - Move platform specific code into subdirectory - Once we have decided whether we want to keep mod_lisp: Refactor so that mod_lisp specific code is isolated or remove it altogether. If you think anything of this is terrible and/or a bad idea, speak up. -Hans
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
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... :)
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.
I suggest Nick Levines cl-log (I haven't looked too closely, but I have the impression that he took what is good about log5 and made it better...). Log5 is probably aso worth looking at. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
I think I will not add a logging subsystem. My plan is to make the log-message function part of the official API and provide for a way to specify the logging function so that everyone can use their own favoured logging framework. -Hans 2008/4/10, Gary King <gwking@metabang.com>:
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.
I suggest Nick Levines cl-log (I haven't looked too closely, but I have the impression that he took what is good about log5 and made it better...). Log5 is probably aso worth looking at. -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
participants (4)
-
Edi Weitz -
Gary King -
Hans Hübner -
vseguip＠gmail.com