From: Chris Beggy
Subject: content management
Date: 
Message-ID: <873cqpkm60.fsf@lackawana.kippona.com>
This was new to me:

  http://fastcm.net/

website content management written in lisp, with config files in
lispy macros.

Chris

From: Marc Spitzer
Subject: Re: content management
Date: 
Message-ID: <Xns92B6A25AEC431mspitze1optonlinenet@167.206.3.3>
Chris Beggy <······@kippona.com> wrote in 
···················@lackawana.kippona.com:

> http://fastcm.net/

it looks like the start of a yahoo store clone.  I need
to take a closer look at this.

marc
From: Chris Beggy
Subject: Re: content management
Date: 
Message-ID: <87u1j4ki1w.fsf@lackawana.kippona.com>
Marc Spitzer <········@optonline.net> writes:

> Chris Beggy <······@kippona.com> wrote in 
> ···················@lackawana.kippona.com:
>
>> http://fastcm.net/
>
> it looks like the start of a yahoo store clone.  I need
> to take a closer look at this.

Yes, it might be.  Have you ever seen the inside of Yahoo Store?

As far as I can see, there isn't any interaction with a server,
in fastcm.

Yahoo Store was very much a web service, wasn't it?

Mark Battayani's mod_lisp for apache would be another part of a 
Yahoo Store engine clone.

Chris
From: Marc Spitzer
Subject: Re: content management
Date: 
Message-ID: <Xns92B6BFFFA7778mspitze1optonlinenet@167.206.3.3>
Chris Beggy <······@kippona.com> wrote in 
···················@lackawana.kippona.com:

> Marc Spitzer <········@optonline.net> writes:
> 
>> Chris Beggy <······@kippona.com> wrote in 
>> ···················@lackawana.kippona.com:
>>
>>> http://fastcm.net/
>>
>> it looks like the start of a yahoo store clone.  I need
>> to take a closer look at this.
> 
> Yes, it might be.  Have you ever seen the inside of Yahoo Store?
> 
> As far as I can see, there isn't any interaction with a server,
> in fastcm.
> 
> Yahoo Store was very much a web service, wasn't it?
> 
> Mark Battayani's mod_lisp for apache would be another part of a 
> Yahoo Store engine clone.
> 
> Chris
> 

no, just what I have read about it.  It used clisp and batch generated a 
static website from a db backend.

marc
From: Christopher Browne
Subject: Re: content management
Date: 
Message-ID: <apng8a$3aqni$1@ID-125932.news.dfncis.de>
Quoth Chris Beggy <······@kippona.com>:
> Marc Spitzer <········@optonline.net> writes:
>
>> Chris Beggy <······@kippona.com> wrote in 
>> ···················@lackawana.kippona.com:
>>
>>> http://fastcm.net/
>>
>> it looks like the start of a yahoo store clone.  I need
>> to take a closer look at this.
>
> Yes, it might be.  Have you ever seen the inside of Yahoo Store?
>
> As far as I can see, there isn't any interaction with a server,
> in fastcm.
>
> Yahoo Store was very much a web service, wasn't it?
>
> Mark Battayani's mod_lisp for apache would be another part of a 
> Yahoo Store engine clone.

The use of CLISP with Yahoo! Store involved a whole lot of
"non-interaction with the server;" it was used in a batch process to
generate lots of HTML for an ordinary web server to serve up.

In effect, Lisp was used at compile time, not at run time.
-- 
(reverse (concatenate 'string ·············@" "sirhc"))
http://www.ntlug.org/~cbbrowne/lsf.html
"Sponges grow in  the ocean. I wonder how much  deeper the ocean would
be if that didn't happen." -- Steven Wright
From: Adam Warner
Subject: Re: content management
Date: 
Message-ID: <pan.2002.10.30.03.31.38.381533@consulting.net.nz>
Hi Christopher Browne,

> The use of CLISP with Yahoo! Store involved a whole lot of
> "non-interaction with the server;" it was used in a batch process to
> generate lots of HTML for an ordinary web server to serve up.
> 
> In effect, Lisp was used at compile time, not at run time.

Graham gave each user their own Lisp image to talk to (just noting this to
make sure other people don't get the impression that Lisp wasn't fully
involved at run time). CLISP has such a small footprint that this kind of
approach is feasible and relatively efficient--and it's a robust
approach.*

In Paul Graham's own words (via Daniel Lakeland):
http://www.red-bean.com/pipermail/lispweb/2001-August/000294.html

   We gave each user their own Lisp image to talk to. So it was no problem
   to have each individual one be single threaded. The OS handled
   scheduling between processes, which seemed a good plan, considering
   it's one of the main things OSes are designed for.  This also meant the
   OS conveniently paged out users who had been idle for a long time.

   Users' data tended to be larger than the code part of the Lisp image,
   most of which was shared anyway, so this was not an inefficient way to
   use memory.

   The OS, BTW, was FreeBSD.  Fortunately, that's what they use throughout
   Yahoo, so we did not have to port anything when they bought Viaweb.

   Sure, by all means post this where you like.

   --pg

Regards,
Adam

*Consider the complications of doing this via CMUCL's co-operative style
multitasking. With multiple lisp images you can have a user lock an image
up without affecting other users (if this happened often enough remaining
resources might become very scarce). Of course you could get the same
robustness using CMUCL the same way. It's just that you'd use up many
times the resources as CMUCL's footprint is much larger than CLISP.