On Fri, Feb 20, 2009 at 11:53 AM, Jochen Schmidt jsc@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.)