A layer for loading and running some Allegro CL projects.
ZACL is for running AllegroServe on non-AllegroCL Lisps. The goal is to run AllegroServe sources with as few modifications as possible, so that such a modified version of aserve will continue to be able to track future versions of official aserve. That means occasionally resorting to grody one-off hacks instead of elegant beautiful gracefulness.
Where possible, ACL functionality is mimicked with portability libraries like UIOP, bordeaux-threads, cl-ppcre, USOCKET, etc. Where necessary, implementation-specific hacks are used to fill in the gaps.
For example, Allegro CL's non-standard
#+(version>= ...) expression
is sprinkled throughout aserve code. To work around the problem
without changing the code, zacl installs a readtable that overrides
#- readers to check for these expressions and
work around them.
Occasionally, quirks in aserve's source may be very difficult to work around. In those cases, a patch or pull request can be [sent to Franz] (https://github.com/franzinc/aserve/). Ideally, the official aserve will eventualy get to where it will work with ZACL unmodified.
But as long as there are discrepancies between what works with zacl and the official Franz version of aserve (as is the case currently), a zacl-compatible fork will be available here. You can check it out like so:
git clone -b master https://github.com/genworks/aserve.git
aserve system definition name conflicts in Quicklisp with a
legacy attempt to port
Therefore, the zacl-compatible
has its system name as
zaserve system definition
includes a dependency on ZACL, so you can load it simply by invoking
Of course, if for some reason you only want the
zacl system itself,
you can load that with
Only works on Clozure CL and SBCL. Support for other implementations may be added if there is sufficient demand. Contributions of ports to other implementations are of course welcome
Does not support CGI. A victim of time constraints. The author and maintainers do not currently need CGI. CGI functionality requires non-trivial support for managing subprocesses, and I am not sure if e.g. UIOP's subprocess management API is sufficient.
Possibly slow. Using generic functions and portability layers will be slower than running aserve natively on Allegro CL. There aren't many ways around it. If you do have a specific performance issue when running with ZACL that you would like to see ZACL try to address, then please open an Issue or get in touch.
With that said, AllegroServe will always run best on its native platform, which is Allegro CL. So if you want to run AllegroServe for mission-critical or performance-critical applications, and with a guarantee of a supported, trouble-free experience, then you may want to consider investing Allegro CL for your AllegroServe needs. This option also comes with the benefit of dedicated, world-class support from Franz Inc. engineers.