hckrnws

How does it compare (feature-wise, performance, stability) with e.g. hunchentoot (which clearly wins the naming contest)?

I think this runs only with Allegro Common Lisp, a commercial implementation.

Not really, you can run this under SBCL too.

I need another hint. The sources seem to depend on Allegro specifics, e.g. the :excl package (with the enlightening description "General extensions to Common Lisp").

You can load :aserve from qucklisp to get a portable fork of AllegroServe that works with sbcl (or at least it appears to at first glance on my copy of SBCL 2.2.6).

The README distributed with the library offers a little guidance to getting started.

Yes, AllegroServe is Allegro specific, but there is Portable AllegroServe: http://portableaserve.sourceforge.net/

It's the same situation as OpenSSH. OpenSSH only runs on OpenBSD, and Portable OpenSSH is maintained separately.

Five message into the comments and the discussion devolves into compatibility issues between various versions of common lisp.

Welcome to CL hell.

But the conclusion is "yes, there is a portable version", which is pretty amazing considering how many implementations there are!

A google search would point you towards Hunchentoot, and https://github.com/CodyReichert/awesome-cl to a couple choices.

portable common lisp hasn't changed since 1994

I'd also be interested in a feature comparison against Swish (https://github.com/becls/swish), but I'm not actually familiar enough with either to make the comparison myself.

Seems like an unrelated domain; AllegroServe is a web server, Swish looks like a lower-level Erlang-like framework for writing concurrent, fault-tolerant programs. Swish looks very interesting though!

I'd be interested in comparisons with Clack, though, the "other" Common Lisp web framework.

> We've recently added these features:

> [...]

> - Security up through TLS 1.0 (SSL 3.1).

uhhhhhhhh, isn't this removed from Firefox for having security holes fixed in later versions of the TLS spec?

That line is about twelve years old, per git blame. Typically, I’d use a reverse proxy to handle HTTPS anyways.

I would almost prefer a web framework that doesn't even bother trying to handle things like HTTPS and assumes that I'm using a reverse proxy in front of it. Fewer things to maintain.

Is this generally true for compiled languages ?

I like being able to handle https in a single go binary for small projects that otherwise don't need a load balancer etc.

I don't trust random web frameworks to implement HTTPS correctly and there are lots of subtle attacks on cryptography.