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
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
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
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
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.