[hunchentoot-devel] Backtrace display + idea for "representations"

[Edi Weitz]

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 at 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 at 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_stbreak-on-signalsst.html
>> [2] http://common-lisp.net/project/trivial-backtrace/
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>