Proposal for LAIR: Lisp All-Inclusive Repository
I propose that the Lisp community build the Lisp All-Inclusive Repository (LAIR). In a nutshell, it's like CPAN: the place to go to get libraries and such. It's "all-inclusive" in the sense of providing this service for all members of the Lisp family, including Scheme and Dylan and Clojure.
I wrote this after being inspired by the "Clornucopia" idea from Clozure Associates LLC. However, this is my own proposal. I am grateful for Clozure's inspiration, but I'm speaking only for myself.
"Put the source code out there and let all persons play with it. Have a person in charge who is a quick judge of good work and who will take it in and shove it back out fast. You don't have to use what he ships, and you don't have to give back your work, but he gives all persons a fast way to spread new code to those who want it."
-- Guy Steele, "Growing a Language", Oct 1998
The High-level Goals
Make Lisp a more attractive choice of language(s), by helping to solve one of its most important perceived drawbacks: the lack of a robust set of libraries and a way to find them and select among them. (Different Lisp family members suffer from this problem to a greater or lesser degree.) Increase the size of the Lisp community.
As the size of the Lisp community increases, we'll get more libraries, more tools, better testing, and more portability. Lisp will be perceived less as "dead" and more as "constantly improving". All of this will, in turn, grow the community even more, which will get us more and better libraries.
Provide the kind of benefits that CPAN provides for the Perl community; be just as good as CPAN at the things it does. This repository can be thought of as "CPAN For Lisp".
The Problem We're Addressing
The most prominent complaint about Common Lisp in particular, and a main barrier to choosing Common Lisp, is the perceived lack of libraries for commonly-needed abilities. Here are some of the ones mentioned most often, although this not an exhaustive list:
* Extensible (user-defined) streams
Is the perception reality? There are a lot of libraries available at sites like cl-user.net and cliki.net. But there are many problems for users:
* Users have to know where to find sites like cl-user.net and cliki.net
It's also unfortunate that when there are many libraries to do the same thing, the effort of the open source community gets diluted.
If you want evidence that this is a real problem, I can show you many, many blog comments, discussion threads, mail from Lisp user's groups, and so on.
What It Provides
Provide a repository of libraries, addressing at least the areas listed above, that are, to the greatest extent possible:
* Actively maintained
The repository stores the following:
* The source code itself, for open-source libraries
Allow for different libraries that do roughly the same thing, such as multiple HTTP servers.
* Useful for more advanced users, who can figure out how to decide which to use.
In addition to libraries, store named collections of libraries (and of collections). These have some of the same metadata as shown above. Collections are intended to be a set of libraries that work well together. You don't have to download everything in a library all at once. Also store other resources such as documents and applications.
Provide one special default collection, which has one of every kind of library, e.g. one HTTP server, etc.
* Useful for beginners, who don't want to have to choose between, say, multiple alternative HTTP servers.
There is a common user interface for accessing and searching the repository. Most of it is on a web site. Of course, it should be as easy to learn and use as possible. Some of it is for users looking up existing resources, allowing them to search by various criteria, including full-text search. The rest is for developers adding and modifying resources, and LAIR administrators.
Some software is needed inside Lisp, to actually connect to the server and bring over libraries, etc. Each Lisp implementation should have a function that starts up this software, named the same thing in all implementations. This could just be a small function that loads in the real client side, in case an implementor wants to keep the implementation as small as possible.
Keep a local cache (in the file system) of everything you've downloaded, so that you don't have to do it again. There's a little local database to keep track of what's in the cache. The client-server protocol has a fast way to specify a set of libraries and versions, and find out which are out of date, and there's an easy way to update them or flush them from the cache.
LAIR is highly-available. E.g., use mirrors, or a highly-available cloud.
What We Need
* Detailed design
Initially, we must find the proper funding sources and appropriate volunteers.
Active forum topics
New forum topics