[hunchentoot-devel] New releases of Hunchentoot, Drakma, and Chunga

[Edi Weitz]

On Fri, Feb 20, 2009 at 11:53 AM, Jochen Schmidt <jsc at crispylogics.com> wrote:

> Hans said it was removed because it was the only remaining non-portable
> part.

More or less.  We still maintain a portability layer for timeouts as
usocket can't deal with them.  We also have a special case for CCL
"deadlines".

> As printing backtraces isn't really a core functionality of a
> webserver I do not understand why having it only for lw (with conditionals)
> would have been such a big problem?

I don't understand the question.  The previous release had backtrace
functionality for all supported Lisps.

> Just to make it clear - I personally do
> not miss it - but I would miss some other parts in hunchentoot were
> Lispworks is specially handled instead of using what is implemented for
> other lisps (e. g. some taskmanager stuff). There was a time in
> hunchentoot-dev development were I guessed Hans would throw the baby out
> with the bath water ;-) - I'm happy to see that this didn't happen.

As you might know, Hunchentoot was historically a LW-only library and
thus its architecture was based in part on LispWork's way of
implementing TCP/IP servers.

While Hunchentoot now aims to be portable to several Lisp
implementations, my policy still is that I care mostly about the
LispWorks port and that's the one I'm working and testing with.  Also,
I don't want to deal with gazillions of portability libraries just to
load a pretty simple and straightforward web server.  (I would make an
exception for trivial-backtrace as it seems pretty small and
self-contained.)

There's also a technical reason for keeping LW-specific stuff in
there: Doing things the way they are done in usocket now would mean
that we'd have to use undocumented and unsupported features of
LispWorks.  I don't think that's a good idea.

So, if you're missing anything specifically for LispWorks or if you
think the situation for LispWorks became worse due to the new release,
I'm all ears.  (Except for the debugging stuff we already discussed.
See next release.)