From: Srini
Subject: CL-HTTP and AllegroServ
Date: 
Message-ID: <3B9A92B6.AC65BF51@lucent.com>
I am looking for a comparative analysis of two Web Servers CL-HTTP and
AllegroServ.
If anyone  has the info, please point me to that or post it here. Since
both
seems to be open source/public domain, I am not sure why there are two
in the first place. There may be some good reasons for it.

Thanks
srini

From: Kent M Pitman
Subject: Re: CL-HTTP and AllegroServ
Date: 
Message-ID: <sfw7kv9c8gc.fsf@world.std.com>
Srini <······@lucent.com> writes:

> I am looking for a comparative analysis of two Web Servers CL-HTTP and
> AllegroServ.
> If anyone  has the info, please point me to that or post it here. Since
> both
> seems to be open source/public domain, I am not sure why there are two
> in the first place. There may be some good reasons for it.

I don't think either is "public domain".  AllegroServe definitely is not,
but at least has "certain and known legal status".  At least one reason 
for making AllegroServe would have been that the legal status of CL-HTTP
is slightly more uncertain.

In general, however, there is no required "reason" for having two servers.
I have my own server (not available publicly) just because I wanted to.
Even if it turned out there was no material difference between mine and 
others, the mere fact of having something in my own control is reason enough.

Incidentally, if people DID give away software as truly "public domain", I
might agree with you that having separate branches was less important.  But
since most people use GPL or LGPL and since the whole point of those licenses,
in spite of flowery and misleading verbiage to the contrary, is to coerce or
restrict behavior in ways that mere "public domain" software would not, the
most obvious reason for diverging is the one I have for having made mine: 
freedom.  You don't get true freedom from using someone else's software if 
tha software comes with a license of ANY kind; you only get it if you make
your own.
From: Andy Freeman
Subject: Re: CL-HTTP and AllegroServ
Date: 
Message-ID: <8bbd9ac3.0109100708.40b7c486@posting.google.com>
Srini <······@lucent.com> wrote in message news:<·················@lucent.com>...
> I am looking for a comparative analysis of two Web Servers CL-HTTP and
> AllegroServ.
> If anyone  has the info, please point me to that or post it here. Since
> both
> seems to be open source/public domain, I am not sure why there are two
> in the first place. There may be some good reasons for it.

I don't know why someone would be surprised by the existence of multiple
web servers in CL.  There are dozens, if not hundreds, of "open source"
text editors.  There are webservers in multiple languages.  (In Python,
there are at least five OS web servers, and at least one (actively used)
web server building toolkit that is OS; the latter's popularity suggests
that lots of folks are rolling their own python web servers.)  There are
webservers in scheme as well.

Kent pointed out why the "open source" licenses are a reason for multiple
similar things.

There are at least three other reasons.  (1) ego, (2) education (both of
self and "to show others"), (3) different goals/functionality.

Never underestimate "because I can" (or "it seemed like a good idea at
the time") as a reason for people to do things.

-andy
From: Tim Bradshaw
Subject: Re: CL-HTTP and AllegroServ
Date: 
Message-ID: <ey31ylfnjfa.fsf@cley.com>
* Andy Freeman wrote:

> Never underestimate "because I can" (or "it seemed like a good idea at
> the time") as a reason for people to do things.

I think another reason is because it's so easy.  I needed a small
single-purpose web server for an application I was writing, and it
took me something like 2 or 3 hours to write it (maybe less, I didn't
time it).  It would probably have taken me significantly longer than
that to fetch, build and understand another server well enough to make
it do what I needed.

--tim
From: Kent M Pitman
Subject: Re: CL-HTTP and AllegroServ
Date: 
Message-ID: <sfwelpeiwkj.fsf@world.std.com>
······@earthlink.net (Andy Freeman) writes:

> I don't know why someone would be surprised by the existence of multiple
> web servers in CL.  [...]
> 
> Kent pointed out why the "open source" licenses are a reason for multiple
> similar things.
> 
> There are at least three other reasons.  (1) ego, (2) education (both of
> self and "to show others"), (3) different goals/functionality.

On reflection, I'll add a fourth additional reason:

(4) global societal robustness against viruses.

The more independent implementations of a network protocol there are,
the harder it is for a single bug in one of them to bring down the entire
world's networks, as happened recently with the code red nonsense.

This argument is well-known in the circles where people talk about
opposition to cloning in animals and people.  Some people are just
panicked by cloning because it threatens their moral foundation or
confuses them intellectually, but some have quiet legitimate concerns
about vulnerability of populations to loss in a single castrophic
incident to due to lack of genetic diversity.  This same concern, it
seems to me, should be applied to centralization of software sourcing
whether through a single, free implementation (at one end of the
spectrum) or through a monopolistic commercial encroachment (at the
other end).  Diversity, whatever its economic basis, is a virtue.

I have also found that network and document specifications are often
ill-specified and that the reason no one notices is that they all use
a single code branch that was written by someone who either had
additional metaknowledge not manifest in the spec, or that had an
idiosyncratic way of doing things that did not excercise the problems
in a way that other implementations might have.  I found some problems
in the XML spec that I reported and got back the answer "other people
have managed to figure it out" (the implication being that I was just
confused), which I am convinced meant those others were "in on the
design" and/or using some widely advocated reference implementation
(with its associated presumptions) rather than truly starting from
scratch.

Common Lisp itself had many long-standing confusions and ambiguities
of expression that were only noticed and sorted out by latecomers to
the table who tried to interpret CLTL from scratch rather than being
insiders to its original designed.  An interesting one was the
definition of DEFVAR, which said that the init was only evaluated if
needed, and which Robertson Common Lisp (the Lisp that later became
Symbolics CLOE) interpreted to mean that DEFVAR'd variables had to
remember the form that initialized them, remain unbound, and become
bound on first use (i.e., when the value was needed).  (Even
left-to-right order of evaluation almost got left out. It is mentioned
in only three places in CLTL: in the description of SETF and DEFSETF,
and in the discussion of arithmetic type contagion, where each of
these facilities mention they preserve the normal left-to-right order
of evaluation.)  More implementations mean more people find stuff
like this faster.
From: ········@acm.org
Subject: Re: CL-HTTP and AllegroServ
Date: 
Message-ID: <79zp7.12087$TN5.1282382@news20.bellglobal.com>
Kent M Pitman <······@world.std.com> writes:
> This argument is well-known in the circles where people talk about
> opposition to cloning in animals and people.  Some people are just
> panicked by cloning because it threatens their moral foundation or
> confuses them intellectually, but some have quiet legitimate
> concerns about vulnerability of populations to loss in a single
> castrophic incident to due to lack of genetic diversity.  This same
> concern, it seems to me, should be applied to centralization of
> software sourcing whether through a single, free implementation (at
> one end of the spectrum) or through a monopolistic commercial
> encroachment (at the other end).  Diversity, whatever its economic
> basis, is a virtue.

It _appears_ that the Dolly clones are substantially more vulnerable
to cancer than the original instantiation of that sheep.

It seems not unlikely to me that this represents an inherent
limitation on "unrestricted cloning."

And it suggests that "bit-rot" isn't just a vague computer rumour :-).

> I have also found that network and document specifications are often
> ill-specified and that the reason no one notices is that they all
> use a single code branch that was written by someone who either had
> additional metaknowledge not manifest in the spec, or that had an
> idiosyncratic way of doing things that did not excercise the
> problems in a way that other implementations might have.  I found
> some problems in the XML spec that I reported and got back the
> answer "other people have managed to figure it out" (the implication
> being that I was just confused), which I am convinced meant those
> others were "in on the design" and/or using some widely advocated
> reference implementation (with its associated presumptions) rather
> than truly starting from scratch.

There have been a couple of occasions when grave flame wars have
arisen when Linus Torvalds wanted to pick a different
(conformant-to-POSIX) behaviour than was the convention in the past.

Making the change would probably break a bunch of code; that code was
dependent on behaviour outside the standard that was possibly even
_WRONG_.
-- 
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.cbbrowne.com/info/internet.html
What is a free "gift"? Aren't all gifts free? 
From: Espen Vestre
Subject: Re: CL-HTTP and AllegroServ
Date: 
Message-ID: <w6n13tudr8.fsf@wallace.ws.nextra.no>
········@acm.org writes:

(Kent Pitman:)
> > castrophic incident to due to lack of genetic diversity.  This same
> > concern, it seems to me, should be applied to centralization of
> > software sourcing whether through a single, free implementation (at
> > one end of the spectrum) or through a monopolistic commercial
> > encroachment (at the other end).  Diversity, whatever its economic
> > basis, is a virtue.

My favourite expression in internal security discussions these days
is "security through diversity": The Holy Consulting Company Grail
of the Single Unified Software Platform (read: Windows+Office+Outlook)
has made companies (and home users) extremely vulnerable to worms,
trojans and viruses, because the enviroment which the penetrating
software must adjust to is so extremely predictable.

> It _appears_ that the Dolly clones are substantially more vulnerable
> to cancer than the original instantiation of that sheep.

Quite OT, but: I don't know the background for that statement but be
aware that as far as I've heard, the Dolly clones are not really
genetically identical: The "forgot" to take into consideration
mitochondrial DNA which is inherited from the mother, i.e. the egg
cell which DNA was injected into, only.

-- 
  (espen)