Location via proxy:    [Report a bug]   [Manage cookies]    No cookies    No scripts    No ads    No referrer    Show this form

Portable AllegroServe

Portable AllegroServe is a fork of the AllegroServe webserver, adapted to work with other CL implementations, not only with Allegro CL. So far the following implementations are supported, to varying degrees:

• CMU Common Lisp
• Steel Bank Common Lisp
• GNU clisp (only single-threaded operation)
• OpenMCL
• Xanalys Lispworks
• MCL
• Scieneer Common Lisp (slightly broken as of 2004-02-29)
• Corman Common Lisp (with non-standard install method, might be broken as of 2004-02-29)
• Allegro Common Lisp

• Our SourceForge project summary

Allegro CL users might prefer use the original AllegroServe, which can be found here; it's included in the ACL distribution as well.

Why a fork?

When John Foderaro wrote AllegroServe, his two main goals were the following:

1. Write an industrial strength web server that could compete in reliablity and speed against the best currently out there, and that could better them in dynamic page generation capability through use of a serious programming language (Lisp) over a toy scripting language.
2. Show by example how to do network and multi-threaded programming in Allegro CL. When you go to a bookstore you don't see a wall full of books on network programming in Lisp. All the novice programmer gets is a list of functions and he has to figure out the idioms for combining them. With AllegroServe we can say, "This is one way of doing it we know works in ACL." AllegroServe is written in a subset of CL that maximizes readability. The hope is that AllegroServe is read by programmers and not just run.

Here's what he writes about portability:

As for the issue of portability of AllegroServe between Lisps that is neither a goal nor a non-goal. If portability were a goal then AllegroServe would have been written much differently: I would have written a layer to separate the Ansi from the non-Ansi parts. That layer would have had well defined semantics so that in each Lisp glue code could written to enable that lisp to plug into the interface. This is do-able but it doesn't get me to either of my goals:

1. portable programs work in the least common denominator of the capabilties of the target platforms. I have a lot of control over things I can add to ACL to make it achieve the speed/reliability goal but I have no control over the other lisp implementations. Likewise other Lisps may have special features that I can't make use of since not all other Lisps have equivalent features.
2. It's easier to understand network programming for any single Lisp than for an ad hoc abstraction layer on top of a set of Lisp implementations. Thus my goal is better served by writing in the ACL network and threads interface.

[Read the entire message]

We liked AllegroServe, but wanted to use it on other CL implementations as well, not just Allegro CL. For us that is more important than serving as an example of how to do network programming in Allegro CL. We are also willing to sacrifice some speed for portability.

Porting strategy

AllegroServe is undergoing active development, and we would like to be able to incorporate the changes (new features and bug fixes) into Portable AllegroServe. Therefore, we try to change as little as possible in the AllegroServe source files; instead, we've written an ACL compatibility layer which tries to emulate ACL's networking support, multiprocessing support and so on.

---

Last modified: Sun Jun 9 15:14:26 CEST 2002