Jochen, this is another email I unfortunately haven't replied to yet. Sorry again.
I can kind of understand that the concept of representation classes is tempting in terms of a clean architecture, but right now I fail to see what it would give us in practice. Could you provide an example of how one would extend this mechanism to do something that can't be done right now (or only in a "dirty" way)?
Thanks, Edi.
On Thu, Sep 3, 2009 at 9:30 AM, Jochen Schmidt jsc@crispylogics.com wrote:
Hans,
As outlined before - *break-on-signals* is not a good solution. Not all conditions are errors or useful break points. If we really have to fallback to ANSI CL means for that purpose, wrapping a handler-bind like in Andreas' Solution is better - I use something similar in my code (Actually I do handle all conditions in my handlers now, because I didn't get hunchentoots error handling to do what I wanted). Documentation may help, or not; some clear protocols would be perfect :-)
Hunchentoot evolved really well towards 1.0. I really appreciate the extensibility one now gets through some clearer protocols (task- managers, request-/reply-class a. s. o.). I still see some open problems though. Hunchentoot completely misses the concept of a "representation" - instead it uses either strings or octet-streams directly in an ad hoc way. Perhaps it would be a good idea to abstract this underlying representations using a small set of extensible representation classes? Something like:
representation | / | \ | | string-representation | | | file-representation | stream-representation
A handler would then not either return a string or write itself into the stream one gets from send-headers, but it would generate (or select) a representation object and hunchentoot handles this automatically.
ciao, Jochen
-- Jochen Schmidt
Am 03.09.2009 um 08:45 schrieb Hans Hübner hans.huebner@gmail.com:
We have removed the backtrace support from Hunchentoot because we wanted to get rid of all non-essential system dependencies. For interactive debugging, the *BREAK-ON-SIGNALS* special variable can (should) be used, it can do what the presented acceptor subclass can do. If you really need backtraces in your log files, the trivial-backtrace [2] library may be useful.
It would be useful to have a section on debugging in the manual.
-Hans
[1] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/var_stbrea... [2] http://common-lisp.net/project/trivial-backtrace/
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel