>The apparent thirst on this newsgroup for pursuing a "gimme free stuff"
>seriously irks me.
There was a post from a person who offered to buy the tex or
postscript file from PG but recieved no reply.
>It might be, indeed, that he just doesn't care about the revenue from
>the book any more
That is likely.
After all, he did sell his company for 40 million $ to Yahoo....
>It migth be that he's very busy and plans to republish the book when he
>gets the chance.
Good reason to post these messages, dont you think ?
>But it's his book, and his right to do with it as he wishes. And
>meanwhile, there are others with books that need buying to support
>other authors.
>You may, by the way, think that a publisher is just a nameless entity
>that is profiteering off of our community. But I *want* publishers to
>make as much money off of our community's books as they can
Hmm....
Brain Research ( published by Springer Verlag ) is currently 17,000 $
for a one year subscription. Guess which journal our library will not
be subscribing to this year....
From: Kent M Pitman
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <sfw1ypqk7u4.fsf@world.std.com>
raj <········@optushome.com.au> writes:
> There was a post from a person who offered to buy the tex or
> postscript file from PG but recieved no reply.
This does not seem relevant to me. It is the right of any of us to write
to an author or publisher if we can find an address. It is not our right
to demand an answer, nor to infer anything from the lack of an answer.
> >It might be, indeed, that he just doesn't care about the revenue from
> >the book any more
>
> That is likely.
> After all, he did sell his company for 40 million $ to Yahoo....
That may have been for stock. We don't know if he cashed it at the
right time. We also don't know what part is/was liquid. We don't know
if he spent it on a house which has premium payments due that in today's
lagging economy are hard to make. We don't know if he blew it in Las Vegas.
We don't know what any of his financial commitments are. Nor are they any
of our business even if we did know.
What we do know is that he has an item of value and that people are rallying
to say he should put it up for free. Again, let me repeat: Fine for an
individual to say in private mail. Bad to do in public.
It is simply inappropriate to assume that even millionaires don't have
to eat. It is highly rude for any of us to speculate and presume in
the kind of fashion that you appear to be presuming by your remark about
his having made money on some other enterprise.
> >It migth be that he's very busy and plans to republish the book when he
> >gets the chance.
>
> Good reason to post these messages, dont you think ?
No. Absolutely not. This is like proposing to someone on TV. It may be
very romantic if the person wants to say "yes" but you'd better be darned
sure that's what they plan to say before you do it. Otherwise, it is a huge
public embarrassment that you have no right to turn on them because everyone
gets to watch the person being asked the question give a disappointing answer
and that person feels like a jerk.
> >You may, by the way, think that a publisher is just a nameless entity
> >that is profiteering off of our community. But I *want* publishers to
> >make as much money off of our community's books as they can
>
> Hmm....
> Brain Research ( published by Springer Verlag ) is currently 17,000 $
> for a one year subscription. Guess which journal our library will not
> be subscribing to this year....
I don't understand why this is relevant. People boycott items priced
too high. Are you saying you're boycotting PG's book and that you'll
continue to do so until it's free? I doubt it. If you were, that would be
a statement that the book was worthless. This is a discussion about a book
that is believed to be worth something to people. And my point is that
when something is worth something to someone, it is the right of the creator,
of all people, to assert that worth.
Thaddeus L Olczyk <······@interaccess.com> writes:
> Paul,
> I am writing this to make a request of you. If you find that
> there is no way that your books will be in print once again, of if
> the likelyhood is that they will not, then please make some
> viewable/readable form of these books available on the web.
Kent M Pitman <······@world.std.com> writes:
> What we do know is that he has an item of value and that people are
> rallying to say he should put it up for free. Again, let me repeat:
> Fine for an individual to say in private mail. Bad to do in public.
It seems to me that the request was for him to make the book(s) freely
available *iff* Graham doesn't think he will be making any more money
off of them. I certainly think that making this request in a public
forum is amazingly tacky, but I thought the first clause of the second
sentance of the letter made the request reasonable: a negative
response (or a lack of response) would in this context indicate that
he probably thinks the books are still of value.
From: Kent M Pitman
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <sfwlmnyfdg4.fsf@world.std.com>
···@avalanche.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Thaddeus L Olczyk <······@interaccess.com> writes:
>
> > Paul,
> > I am writing this to make a request of you. If you find that
> > there is no way that your books will be in print once again, of if
> > the likelyhood is that they will not, then please make some
> > viewable/readable form of these books available on the web.
>
> Kent M Pitman <······@world.std.com> writes:
>
> > What we do know is that he has an item of value and that people are
> > rallying to say he should put it up for free. Again, let me repeat:
> > Fine for an individual to say in private mail. Bad to do in public.
>
> It seems to me that the request was for him to make the book(s) freely
> available *iff* Graham doesn't think he will be making any more money
> off of them. I certainly think that making this request in a public
> forum is amazingly tacky, but I thought the first clause of the second
> sentance of the letter made the request reasonable: a negative
> response (or a lack of response) would in this context indicate that
> he probably thinks the books are still of value.
I've been making a comment about politeness, not about the abstract
concept of wanting this particular hypothetical situation.
It can BOTH be reasonable to wish that a person of means offer
contributions to your cause AND rude to the point of counterproductive
to stand up in public and request it. Such, I think, is the case here.
You could say that every charity that calls my house has a point. "IF
you could spare the money," they always begin. But the more that
call, the less I want to give, to the point that I have adopted a
policy that I don't give to organizations nor buy from companies that
telemarket me. This is not a statement about the goodness of their
cause or product. This is a statement about their respect for me
personally.
I get "reasonable" requests like this all the time for my writings.
(Usually my creative writings. I don't think people here on this
newsgroup complain that I post too little.) It's flattering at one
level to get fan mail--nice to know that people care that I write
more. I treat it as a valuable commodity and try to take it VERY
seriously. But it also creates a source of enormous stress because
often I am failing to write NOT because I didn't think of it, but
because I am oversubscribed. I am probably already carrying enormous
guilt for not getting to everything people wish I'd do, and I am often
staying up late and workign very hard trying to do everything that the
world expects of me. In that context, coming up to me and saying "why
don't you spend more time writing" is an EQ statement to "why don't
you spend less time sleeping than you already do"? To me, there's a
sea of difference between "we really enjoy your stories and look
forward to your next one" and "i'm really pissed that you haven't made
stuff available to me recently". And, perhaps because I'm projecting,
the message to Paul above strikes me as being of the latter kind. The
letter superficially suggests that it's a mere oversight on his part
that this situation has happened, whereas to me it seems to me like
the sender can't be polite about not getting a personal reply and is
now escalating the situation to retaliate against him for not replying
by threatening to have others pester him, too. Maybe it's just me,
but it seems highly insensitive.
Btw, I don't know Paul very well, having only spoken to him a handful
of times, but my impression is that if he had more time, he might tell
you that what stands between you yourself and making millions is not
the purchase of his or anyone's books but just plain getting out there
and finding any of the myriad business opportunities that are sitting
there waiting for someone to take them.
And if you think all that stands between you and succeeding on a juicy
business topic is that one book, then find a way to borrow, rent, or buy
the book from someone else. If you think this problem is insurmountable,
you need a book on problem solving, not on programming.
From: Tim Bradshaw
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <nkjlmnxr0zs.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
> Btw, I don't know Paul very well, having only spoken to him a handful
> of times, but my impression is that if he had more time, he might tell
> you that what stands between you yourself and making millions is not
> the purchase of his or anyone's books but just plain getting out there
> and finding any of the myriad business opportunities that are sitting
> there waiting for someone to take them.
>
> And if you think all that stands between you and succeeding on a juicy
> business topic is that one book, then find a way to borrow, rent, or buy
> the book from someone else. If you think this problem is insurmountable,
> you need a book on problem solving, not on programming.
I'm just following up to this so the text above appears in more
articles. Just do it, don't wait for some book.
--tim
On 16 May 2001, Tim Bradshaw wrote:
> Kent M Pitman <······@world.std.com> writes:
[snip]
> > And if you think all that stands between you and succeeding on a juicy
> > business topic is that one book, then find a way to borrow, rent, or buy
> > the book from someone else. If you think this problem is insurmountable,
> > you need a book on problem solving, not on programming.
>
> I'm just following up to this so the text above appears in more
> articles. Just do it, don't wait for some book.
Continuing this action, but adding a point.
I like *On Lisp* as a read. In general, I enjoy nice written, interesting,
thoughtful technical literature, and, for that reason, it be nice if *On
Lisp* were more readily available.
I'd almost rather that it *wasn't* made downloadable, *if* this lead to
continued lack of a printed version.
And I agree that it's not the *sine qua non*. And I don't think I'd pay
$200 for a copy. However, I think it's really worth having in print.
Weird note: I was praising it's discussion of closures off handedly to a
Perl guy (who had mentioned *Object Oriented Perl*'s discussion), and
1) he said he couldn't find it, never seen it, wasn't availible so 2) Lisp
was dead, 3) lisp authors were all academic wankers who used confusing
language, 4) thus (common) lisp was only used in academia etc., etc.,
etc. (note, some of the "thus"s ran several ways, depending on the stage
of the conversation).
However, my reaction wasn't "Oh my god, the Lisp community must generate
books to expand mindshare," but "Oh boy, what an idiot."
Hmm. While we're talking book wishes, extracting the Lisp advice bits of
Norvig's PAIP (which is a fine fine book overall) seems like a feasible
and worthwhile project, if just so I could recommend it to folks without
having them give me a hard time with the "AI" word :)
Cheers,
Bijan Parsia.
From: F. Xavier Noria
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <3b0370ef.1598314@news.iddeo.es>
On Wed, 16 May 2001 18:35:51 -0400, Bijan Parsia <·······@email.unc.edu> wrote:
: Weird note: I was praising it's discussion of closures off handedly to a
: Perl guy (who had mentioned *Object Oriented Perl*'s discussion), and
: 1) he said he couldn't find it, never seen it, wasn't availible so 2) Lisp
: was dead, 3) lisp authors were all academic wankers who used confusing
: language, 4) thus (common) lisp was only used in academia etc., etc.,
: etc. (note, some of the "thus"s ran several ways, depending on the stage
: of the conversation).
I asked in comp.lang.perl.misc whether anyone had considered to use
closures to store session state in web applications as Paul Graham
explains in the continuation of "Beating the Averages" [*].
I found respect there, the discussion wasn't too much deep but the
idea sounded elegant and people contributed to the thread. The lack
of macros in Perl could make that approach impractical and it wasn't
clear how one could have a hash with the closures in memory if
requests could be directed to more than one process in the web server,
which seems to be the only reasonable scenario (this is something to
solve in the Lisp application as well).
-- fxn
[*] http://www.paulgraham.com/lwba.html
"F. Xavier Noria" <···@isoco.com> wrote in message
·····················@news.iddeo.es...
> I asked in comp.lang.perl.misc whether anyone had considered
> to use closures to store session state in web applications
> as Paul Graham explains in the continuation of
> "Beating the Averages".
Session states in web applications are essentially continuations. See the paper
http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz
--
Biep
Reply via http://www.biep.org
On Thu, 7 Jun 2001, Biep @ http://www.biep.org/ wrote:
> "F. Xavier Noria" <···@isoco.com> wrote in message
> ·····················@news.iddeo.es...
> > I asked in comp.lang.perl.misc whether anyone had considered
> > to use closures to store session state in web applications
> > as Paul Graham explains in the continuation of
> > "Beating the Averages".
>
> Session states in web applications are essentially continuations. See the paper
> http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz
Graham's session-state-as-closures technique is a cool hack, but I wonder
how scalable it is. It forces a remote user to be served by the same
Lisp image (on the same machine, obviously) on every transaction. While
it's desirable to do that for caching reasons, etc., it's not great to
rely on that mode of operation: load balancing, hardware failure,
and network problems/instability, to name a few factors, all conspire
against it.
Tim
Tim Moore <·····@herschel.bricoworks.com> writes:
> On Thu, 7 Jun 2001, Biep @ http://www.biep.org/ wrote:
>
> > "F. Xavier Noria" <···@isoco.com> wrote in message
> > ·····················@news.iddeo.es...
> > > I asked in comp.lang.perl.misc whether anyone had considered
> > > to use closures to store session state in web applications
> > > as Paul Graham explains in the continuation of
> > > "Beating the Averages".
> >
> > Session states in web applications are essentially continuations. See the paper
> > http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz
>
> Graham's session-state-as-closures technique is a cool hack, but I wonder
> how scalable it is. It forces a remote user to be served by the same
> Lisp image (on the same machine, obviously) on every transaction. While
> it's desirable to do that for caching reasons, etc., it's not great to
> rely on that mode of operation: load balancing, hardware failure,
> and network problems/instability, to name a few factors, all conspire
> against it.
While these would make slight problems, I think he was trying to make
the client-server connection seem (from the point of view of the
programmer writing the application logic) like a continuous connection
for the term of the interaction: something most of us want to do when
writing web apps. Load balancing could occur on a per-session, rather
than a per-http-request basis. I don't think you'll lose much, at
least on large systems. Hardware and network failure hopefully occur
infrequently enough that this won't happen during the course of a
given session. Otherwise you've got bigger problems.
Tim Moore <·····@herschel.bricoworks.com> writes:
> Lisp image (on the same machine, obviously) on every transaction. While
> it's desirable to do that for caching reasons, etc., it's not great to
> rely on that mode of operation: load balancing, hardware failure,
> and network problems/instability, to name a few factors, all conspire
> against it.
I don't agree. You should trust your hardware, network etc. enough to
be able to assume that each component can serve the same user through a
session.
And I think layer 4 switches like Foundry Server Iron solve the load
balancing issue for you.
--
(espen)
On 7 Jun 2001, Espen Vestre wrote:
> Tim Moore <·····@herschel.bricoworks.com> writes:
>
> > Lisp image (on the same machine, obviously) on every transaction. While
> > it's desirable to do that for caching reasons, etc., it's not great to
> > rely on that mode of operation: load balancing, hardware failure,
> > and network problems/instability, to name a few factors, all conspire
> > against it.
>
> I don't agree. You should trust your hardware, network etc. enough to
> be able to assume that each component can serve the same user through a
> session.
Large websites are complex systems. You can't assume this unless you
build a great deal of redundancy into the system or you don't care that
much if session data is lost.
> And I think layer 4 switches like Foundry Server Iron solve the load
> balancing issue for you.
I think you mean "solve the combination of load balancing and session
affinity" as you can obviously solve load balancing and break session
affinity. Yes, the features of that switch look like they might do the
trick, assuming you're willing to work within the constraints of their URL
and cookie parsing support and also assuming you're willing to put up with
a single point of failure.
I don't want to overstate my "argument": store building, even at Yahoo!,
is not a high volume application and may work fine on a single machine.
Losing intra-page transitions is probably not a huge deal. And I like the
idea of using closures for this application. But I still don't think it
scales well.
Wandering off topic,
Tim
>>>>> "TM" == Tim Moore <·····@herschel.bricoworks.com> writes:
TM> [...] Yes, the features of that switch
TM> look like they might do the trick, assuming you're willing to
TM> work within the constraints of their URL and cookie parsing
TM> support and also assuming you're willing to put up with a
TM> single point of failure.
My understanding is that you need to store the session context
somewhere anyway, closures or not. If you want to avoid the single
point of failure sitting in frot of your server farm, one alternative
might be to decouple your session context storage from the web server
and move it to the back-end. You still need some replication and auto
failover somewhere to satisfy the no single point of failure constraint.
Then the issue becomes whether closures can still the used under this
scheme, and I suspect, for practical purposes, it would be too much
pain to get "persistent" closures. I would be thrilled to see an
elegant solution to this though.
TM> I don't want to overstate my "argument": store building, even
TM> at Yahoo!, is not a high volume application and may work fine
TM> on a single machine.
You don't need a single machine or even the fancy switch, your front
end web servers can possibly do the right thing if you solve the
session-id to lisp image mapping problem in a robust way (possibly
via the same mechanism above).
TM> Losing intra-page transitions is
TM> probably not a huge deal.
I agree, for this to hurt you the likelihood of the lisp server machine
going down while the user has an active session has to be appreciable.
Outside of that, any particular machine doing down does not hurt you.
cheers,
B<more and more OT>M
Tim Moore <·····@herschel.bricoworks.com> writes:
> ... I like the idea of using closures for this application. But I
> still don't think it scales well.
Where is this technique discussed? I'd like to peek in at it and compare
notes. If I understand you correctly, I've used this technique myself,
effectively giving continuation closures a handle and then having the session
call back looking for a continuation by name. If you assume one-time
reuse and timeout, it works pretty well. If you can re-visit the same
continuation more than once or if you can't GC them, it's a problem.
I don't see what the issue is with "scaling", though I can imagine we might
be talking slightly at crossed purposes. When I say "closures" I don't
mean literally (lambda ...) closures [at least not without a little additional
programming work, which I think *could* be done] but rather the general
concept. Could you maybe elaborate on the scaling problems you see so I can
try to see if I'm just missing something obvious?
I may be available to consult on this if someone has a real application
that needs this and needs help working out the syntax details... ;-)
[Such discussion should go through email, though, not newsgroup.]
On Thu, 7 Jun 2001, Kent M Pitman wrote:
> Tim Moore <·····@herschel.bricoworks.com> writes:
>
> > ... I like the idea of using closures for this application. But I
> > still don't think it scales well.
>
> Where is this technique discussed? I'd like to peek in at it and compare
> notes. If I understand you correctly, I've used this technique myself,
http://www.paulgraham.com/lib/paulgraham/bbnexcerpts.txt
> effectively giving continuation closures a handle and then having the session
> call back looking for a continuation by name. If you assume one-time
> reuse and timeout, it works pretty well. If you can re-visit the same
> continuation more than once or if you can't GC them, it's a problem.
>
> I don't see what the issue is with "scaling", though I can imagine we might
> be talking slightly at crossed purposes. When I say "closures" I don't
> mean literally (lambda ...) closures [at least not without a little additional
> programming work, which I think *could* be done] but rather the general
> concept. Could you maybe elaborate on the scaling problems you see so I can
> try to see if I'm just missing something obvious?
Graham does seem to be using real closures. My scaling concerns, as I've
written in other articles, have to do with requiring sessions to always
return to the same machine.
Keeping some kind of server-side state around for sessions, usually in a
relational database, is common enough for those who've tried to jam
session state into hidden form fields and such.
>
> I may be available to consult on this if someone has a real application
> that needs this and needs help working out the syntax details... ;-)
> [Such discussion should go through email, though, not newsgroup.]
Probably too late for Graham :)
Tim
Off-topic post alert. . .if you're not interested in load-balancers hit
'n' now.
Tim Moore <·····@herschel.bricoworks.com> writes:
> Graham does seem to be using real closures. My scaling concerns, as I've
> written in other articles, have to do with requiring sessions to always
> return to the same machine.
As someone pointed out earlier, if you have a reasonably full-featured
load balancer, their approach scales nicely. Insert a load balancer
parcelling initial requests amongst a farm of servers and then turn on
persistence for future requests and you have a robust, simple solution.
FWIW, persistence usually comes in the form of a cookie, an SSL session ID,
or client IP address(es) (NOTE: outside of intranets, the AOL problem makes
using client IP a bad idea).
This does leave the problem of what happens when the persistent server
for XYZ falls over in the middle of a session. AFAIK, I don't know of any
load-balancer that would do anything besides load-balance the client to
a different server.
And all for a few measly $$$ and 4-U (gotta have a redundant pair) of
rackspace.
> Tim
--Brad (they oughta put me in marketing)
Kent M Pitman <······@world.std.com> writes:
> I may be available to consult on this if someone has a real application
> that needs this and needs help working out the syntax details... ;-)
> [Such discussion should go through email, though, not newsgroup.]
Might I suggest the lispweb mailing list as a forum for such
discussion.
See http://www.red-bean.com/lispweb
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
Craig Brozefsky <·····@red-bean.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > I may be available to consult on this if someone has a real application
> > that needs this and needs help working out the syntax details... ;-)
> > [Such discussion should go through email, though, not newsgroup.]
>
> Might I suggest the lispweb mailing list as a forum for such
> discussion.
>
> See http://www.red-bean.com/lispweb
To clarify, I intended to suggest that the discussion of scaling lisp
applications could be moved to lispweb where there are many people
interested in the topic, and alot of people with experience in the
topic.
It was in no way intending to suggest that discussion with Kent about
consulting on the topic of scaling lisp web apps should go to that
list.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
"Indifference is the dead weight of history." -- Antonio Gramsci
Reply via http://www.biep.org
"Kent M Pitman" <······@world.std.com> wrote in message
····················@world.std.com...
> Where is this technique discussed? I'd like to peek in at it and compare
> notes. If I understand you correctly, I've used this technique myself,
> effectively giving continuation closures a handle and then having the session
> call back looking for a continuation by name. If you assume one-time
> reuse and timeout, it works pretty well. If you can re-visit the same
> continuation more than once or if you can't GC them, it's a problem.
Earlier I gave this pointer:
http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz;
I am not sure that answers your question, but it does discuss re-entrance, which
is interent in the WWW model: people can always return to pages they have
visited before.
--
Biep
Biep @ http://www.biep.org/ <·········@my-web-site.com> wrote in message
···················@ID-63952.news.dfncis.de...
> Reply via http://www.biep.org
>
> "Kent M Pitman" <······@world.std.com> wrote in message
> ····················@world.std.com...
> > Where is this technique discussed? I'd like to peek in at it and compare
> > notes. If I understand you correctly, I've used this technique myself,
> > effectively giving continuation closures a handle and then having the
session
> > call back looking for a continuation by name. If you assume one-time
> > reuse and timeout, it works pretty well. If you can re-visit the same
> > continuation more than once or if you can't GC them, it's a problem.
>
> Earlier I gave this pointer:
> http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz;
> I am not sure that answers your question, but it does discuss re-entrance,
which
> is interent in the WWW model: people can always return to pages they have
> visited before.
>
> --
> Biep
>
By the way, if you have problems with this file (as I did), its probably
because it is actually a pdf file, NOT a gz file. I.e., just rename it to
*.pdf and use your pdf reader on it.
Cheers,
John
On Thu, 7 Jun 2001 21:28:30 GMT, Kent M Pitman <······@world.std.com>
wrote:
> Where is this technique discussed? I'd like to peek in at it and compare
This paper might also be relevant:
"The Influence of Browsers on Evaluators or, Continuations to Program Web
Servers"
Christian Queinnec
Proceedings of ICFP '00
SIGPLAN Notices - vol. 35, n. 9, Sep. 2000, page 23
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
> Graham's session-state-as-closures technique is a cool hack, but I wonder
> how scalable it is. It forces a remote user to be served by the same
> Lisp image (on the same machine, obviously) on every transaction. While
> it's desirable to do that for caching reasons, etc., it's not great to
> rely on that mode of operation: load balancing, hardware failure,
> and network problems/instability, to name a few factors, all conspire
> against it.
I think that load balancing is often required because of unnecessary
mistakes.
If you're serving static pages, the current record is at least 3000/sec
on an x86 box (http://uwsg.iu.edu/hypermail/linux/kernel/0104.2/1191.html).
(Yes, there are multiple NICs.) Of course, if you're only serving static
pages, you probably don't care about sessions, but I mention that rate
because it suggests that a single webserver might be able to serve a lot
more traffic than many people expect.
So, how many dynamic pages can a single webserver generate per second?
Naturally, the answer depends on what it takes to generate the page,
but Rushing's Medusa put out did 200 messages/second (for egroups)
from a 400MHz PII. (Medusa is a single-threaded python app. The
execution model looks a lot like co-routines. The code is available
at www.nightmare.com.) That code is basically just a clever front
end for select, so it's the same for any network service.
Those are old numbers - there are faster ways to handle select in
more modern linux/bsd/solaris kernels, and there are faster processors.
In addition, while the python interpreter is single-threaded, other
webservers can make use of multiprocessors. In short, it shouldn't
be too hard to generate/serve 1000 pages/second from a comparable
system running on a high-end, but commodity, 4 processor x86 box. (I
suspect that network i/o will be the bottleneck - we're approaching
low-end PCI limits.) And, how many sites need that kind of capacity
but can't afford to buy something even more capable? (100/sec is
360k/hour, or easily a million/day.)
Ah, but what each page requires 100 joins (or disk i/o)? In that case
the webserver can front-end compute servers. I suspect that a single
webserver can easily front-end a fairly hefty oracle server, say a 16
processor sun box. Using a webserver as a front-end uses connection
bandwidth&processing, but we still should be able to generate 500
pages/sec.
Will some people need even more capacity? Yes, but not many.
-andy
> If you're serving static pages, the current record is at least 3000/sec
> on an x86 box (http://uwsg.iu.edu/hypermail/linux/kernel/0104.2/1191.html).
For more details and fewer errors, see:
http://www.spec.org/osg/web99/results/res2001q2/web99-20010319-00100.html
In particular, spec99 has both dynamic and static pages. In addition,
the 3000 number is NOT pages served, but simultaneous connections
that are getting adequate service. It's doing over 9000 ops/second.
For more information about the workload, see
http://www.spec.org/osg/web99/
The underlying hardware is a 2 processor 1GHz PIII with only 4GB,
but it's only the fastest on "cheap" hardware.
The x86 champ is 8000 connections at 22.7k ops/second from an 8
processor 700MHz PIII-Xeon (and 32GB).
There are even faster results from a 12 processor SUNfire and a
12 processor IBM eServer (RS64). (I didn't see any 3090 followon
results.)
If anything, that's more argument for the feasibility of a single
webserver.
Yes, a single webserver is a single point of failure. Then again,
if your servers aren't on non-adjacent plates (servers on different
sides of the San Andreas fault isn't good enough), you're already
subject to single cause failures. It's hard to do redundancy right,
to get a system that is actually more reliable than its components,
and in many cases, minimizing time to repair/recovery is more important.
-andy
These are interesting stats, and they do show that a single server may be
a viable option for many web applications. Then you can use closures to
your heart's content. I don't like to talk about my employer much in this
forum, and our traffic numbers are a closely guarded secret anyway, but...
there ain't no way we would run the front end of the site on a single
server. I'll leave it at that.
Tim
On 9 Jun 2001, Andy Freeman wrote:
> > If you're serving static pages, the current record is at least 3000/sec
> > on an x86 box (http://uwsg.iu.edu/hypermail/linux/kernel/0104.2/1191.html).
>
> For more details and fewer errors, see:
> http://www.spec.org/osg/web99/results/res2001q2/web99-20010319-00100.html
>
> In particular, spec99 has both dynamic and static pages. In addition,
> the 3000 number is NOT pages served, but simultaneous connections
> that are getting adequate service. It's doing over 9000 ops/second.
>
> For more information about the workload, see
> http://www.spec.org/osg/web99/
>
> The underlying hardware is a 2 processor 1GHz PIII with only 4GB,
> but it's only the fastest on "cheap" hardware.
>
> The x86 champ is 8000 connections at 22.7k ops/second from an 8
> processor 700MHz PIII-Xeon (and 32GB).
>
> There are even faster results from a 12 processor SUNfire and a
> 12 processor IBM eServer (RS64). (I didn't see any 3090 followon
> results.)
>
> If anything, that's more argument for the feasibility of a single
> webserver.
>
> Yes, a single webserver is a single point of failure. Then again,
> if your servers aren't on non-adjacent plates (servers on different
> sides of the San Andreas fault isn't good enough), you're already
> subject to single cause failures. It's hard to do redundancy right,
> to get a system that is actually more reliable than its components,
> and in many cases, minimizing time to repair/recovery is more important.
>
> -andy
>
>
>> Session states in web applications are essentially continuations.
>> See the paper
>> http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz
> Graham's session-state-as-closures technique is a cool hack, but I wonder
> how scalable it is. It forces a remote user to be served by the same
> Lisp image (on the same machine, obviously) on every transaction. While
> it's desirable to do that for caching reasons, etc., it's not great to
> rely on that mode of operation: load balancing, hardware failure,
> and network problems/instability, to name a few factors, all conspire
> against it.
Is there any reason that continuations couldn't be made serializable?
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> >> Session states in web applications are essentially continuations.
> >> See the paper
> >> http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz
> > Graham's session-state-as-closures technique is a cool hack, but I wonder
> > how scalable it is. It forces a remote user to be served by the same
> > Lisp image (on the same machine, obviously) on every transaction. While
> > it's desirable to do that for caching reasons, etc., it's not great to
> > rely on that mode of operation: load balancing, hardware failure,
> > and network problems/instability, to name a few factors, all conspire
> > against it.
>
> Is there any reason that continuations couldn't be made serializable?
Well...
This implies that ALL objects in the system must be serializable,
since there's no restriction about what you might have closed over in
a continuation.
This would also create problems for the GC in that you'd presumably be
taking these things out of view of the system, which would thwart the GC
in a variety of ways.
>> Is there any reason that continuations couldn't be made serializable?
> Well...
> This implies that ALL objects in the system must be serializable,
> since there's no restriction about what you might have closed over in
> a continuation.
Naturally. I suppose this may cause some complications with the
metaobject protocol (have to think about it), or if somebody's gone
and stashed stuff in unrelated property lists.
Streams would possibly be tricky. Most OS's don't allow for
serialized streams, so you'd probably only be able to get a closed
stream back with whatever state the image could keep (EOF, error
status, whatever).
I don't know enough about the range of Lisp implementations to
consider functions.
Nothing else strikes me as Really Hard to serialize, but I'll be the
first to admit I haven't thought about this much.
Of course, you could make an implementation such that continuations
are as serializable as whatever they've closed over, so you may end up
with unreadable objects in the stream. I'd have to think about that
one being in anything released, but it'd be fine for something more
in-house.
> This would also create problems for the GC in that you'd presumably be
> taking these things out of view of the system, which would thwart the GC
> in a variety of ways.
I could see that if, for some reason, you wanted to read back in the
stream and get structures that were EQ to the old structures. I'm not
sure that's really necessary. When you're serializing, you're
generally making the implicit assumption that you're going to be
switching to another Lisp image, so them being EQ to their incarnation
in a different image becomes meaningless.
Instead, when you read it back, you get something that's EQUALP to the
original (and you'd probably guarantee EQL in the case of characters
and numbers), but I don't see how that messes with the GC any more
than more traditional ways of saving state, such as (prin1 state
state-stream) ... (let ((state (read state-stream))) ...)
Or am I missing your point?
Thanks,
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> sure that's really necessary. When you're serializing, you're
> generally making the implicit assumption that you're going to be
> switching to another Lisp image, so them being EQ to their incarnation
> in a different image becomes meaningless.
The subject of this thread, however, is still "Session state in web
applications". For that particular application, I think it very
likely that you'd be reusing the same image - otherwise, what's the point?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Joel Ray Holveck <·····@juniper.net> writes:
>
> > sure that's really necessary. When you're serializing, you're
> > generally making the implicit assumption that you're going to be
> > switching to another Lisp image, so them being EQ to their incarnation
> > in a different image becomes meaningless.
>
> The subject of this thread, however, is still "Session state in web
> applications". For that particular application, I think it very
> likely that you'd be reusing the same image - otherwise, what's the point?
The point is that some web servers exist distributed. The "session" typically
presumes a single browser but may involve multiple web servers, in the case
that one is busy or one goes down. The burden is on the server, not the
client, to provide robustness in the face of a user model that "'something'
is consistently available for me to talk to" not "the self-same server/image
is available for me to talk to". It is the identity of the session and
its associated context, not of the image serving it, that is of critical
improtance here.
So identity across images is relevant both to accomodate one server failing
and another trying to pick up the pieces and also to accomodate dynamic
load balancing, where one server has taken on more tasks than it can handle
efficiently and wants to offload some of them without making end-user clients
start over again.
Joel Ray Holveck <·····@juniper.net> writes:
> Nothing else strikes me as Really Hard to serialize, but I'll be the
> first to admit I haven't thought about this much.
Anything strikes *me* as hard to serialize because Lisp is a language that
cares about identity. Just because you can make a new object doesn't mean
it's the same object. Object sharing is often critical for any object,
and there is no backpointer from an objecto to the things tha tpoint into
it. I marvel that people are able to do as much serialization as they do
in other languages, and find myself wondering if this is because they are
told not to rely on object identity when doing their programming originally.
> > This would also create problems for the GC in that you'd presumably be
> > taking these things out of view of the system, which would thwart the GC
> > in a variety of ways.
>
> I could see that if, for some reason, you wanted to read back in the
> stream and get structures that were EQ to the old structures. I'm not
> sure that's really necessary. When you're serializing, you're
> generally making the implicit assumption that you're going to be
> switching to another Lisp image, so them being EQ to their incarnation
> in a different image becomes meaningless.
>
> Instead, when you read it back, you get something that's EQUALP to the
> original (and you'd probably guarantee EQL in the case of characters
> and numbers),
Ah, so if I coincidentally cons something of similar shape in the same
storage, you're going to believe it's the same? I don't want to see you
try to track down the strange bugs this will lead to. This is NOT
acceptable.
Also, btw, you are saying that you have to save both a representation of
each object AND its storage location. What if the GC simply moves storage,
btw? Then the memory location will be invalid even though the equalp part
will be right. You'll think the object has moved and will cons a second
one, not knowing it hasn't been GC'd.
> but I don't see how that messes with the GC any more
> than more traditional ways of saving state, such as (prin1 state
> state-stream) ... (let ((state (read state-stream))) ...)
Also, again, identity. What if you moved to disk something which needed a
companion piece of state stored in a weak hash table? What assurance that
upon reload the weak hash table would not have lost its piece of companion
state?
> Or am I missing your point?
It's hard to say, but I think so.
Although I understand the mechanism of serialization in other languages,
I don't understand how it can work in the general case without substantial
extra constraint. I suspect it to be the case that while any object is
"in principle serializable", that in fact if all objects were serializable
it would lead to some problems in reconstructing sharing. But that might
be just because I'm ill-practiced at it. (This is like the situation Dorai
was accusing me of being in for Scheme macros, except in this case I AM
an outsider making assumptions about other languages for lack of experience,
and substituting my own experience with Lisp to make up--not really the
right thing to do.)
In general, though, suppose you have an object:
(defclass person ()
((name ...)
(brothers ...)
(sisters ...)
(parents ...)
(children ...)))
and you want to serialize it. I don't see how you can serialize one person
without serializing all people everywhere, which to me seems extreme.
Otherwise, saving the brothers and sisters and so on will either save "similar
but not the same" people or else will save too much stuff. You could save
only their name in a registry, but there might be people with the same name.
You could make an "ID" slot that was more unique than the name, but now you
are talking about custom-crafting your whole object design to make this
data structure serializable. For example, if this were the list datatype,
you couldn't add an extra field "id", because conses have fixed allocation
and there is no place to add an extra cell. You could save the cell's
memory location, but only at the cost of thwarting a relocating GC.
(A similar problem to the one of PERSON above comes up with serializing a
function, which may mean serializing all functions everywhere. Some functions
are like Kevin Bacon, hooks into nearly everything. So any function that
calls ERROR calls FORMAT and any function that calls FORMAT calls almost
everything. Of course, for symbols, you can decide to bottom out at
the package system, and for literal data you can assume it to be possible
to copy and coalesce, but CL has LOAD-TIME-VALUE, which many languages
don't, and so code can also contain pointers to data whose identity matters,
and that cannot be split or coalesced... and that's a problem again.)
From: Tim Bradshaw
Subject: Re: Session state in web applications
Date:
Message-ID: <nkj4rtlu1lk.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
> Anything strikes *me* as hard to serialize because Lisp is a language that
> cares about identity. Just because you can make a new object doesn't mean
> it's the same object. Object sharing is often critical for any object,
> and there is no backpointer from an objecto to the things tha tpoint into
> it. I marvel that people are able to do as much serialization as they do
> in other languages, and find myself wondering if this is because they are
> told not to rely on object identity when doing their programming originally.
I've always been terrified by this kind of thing. Java makes
serialisation claims, and I really have now idea what it does. Either
it does it wrong, or as far as I can see you need to keep something
like an EQL hashtable of everything-you-have-ever-serialised and use
that to maintain EQLness on the far side. Which is expensive.
I suspect - like you perhaps - that object identity is not so much
relied-on in some other languages. Perhaps this is because
object-ownership issues are so bad in a non-GCd language that it's
less painful to copy things all the time. Presumably this has
persisted in java for cultural reasons...
(a CORBA person is now going to explain how it solves all these
problems at a stroke, I can feel it...)
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Anything strikes *me* as hard to serialize because Lisp is a
> > language that cares about identity. Just because you can make a
> > new object doesn't mean it's the same object. Object sharing is
> > often critical for any object, and there is no backpointer from an
> > objecto to the things tha tpoint into it. I marvel that people
> > are able to do as much serialization as they do in other
> > languages, and find myself wondering if this is because they are
> > told not to rely on object identity when doing their programming
> > originally.
>
> I've always been terrified by this kind of thing. Java makes
> serialisation claims, and I really have now idea what it does. Either
> it does it wrong, or as far as I can see you need to keep something
> like an EQL hashtable of everything-you-have-ever-serialised and use
> that to maintain EQLness on the far side. Which is expensive.
>
> I suspect - like you perhaps - that object identity is not so much
> relied-on in some other languages. Perhaps this is because
> object-ownership issues are so bad in a non-GCd language that it's
> less painful to copy things all the time. Presumably this has
> persisted in java for cultural reasons...
>
> (a CORBA person is now going to explain how it solves all these
> problems at a stroke, I can feel it...)
Perhaps they (either Java or CORBA or anything else that thinks
serialization can work reliably) take as axiomatic the idea that
serialization does or must work and consider that any data structure
you make that cannot be serialized is the error.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Perhaps they (either Java or CORBA or anything else that thinks
>serialization can work reliably) take as axiomatic the idea that
>serialization does or must work and consider that any data structure
>you make that cannot be serialized is the error.
I think this is a likely case for any distributed data architecture. It's
also pretty common in database architectures. Rather than worrying about
object identity provided at the language level, data is often
self-identifying; for instance, in a banking application, the object
representing an account will include an account number slot, and a
relational database used to manage the accounts would probably declare this
as a unique index.
A serialization libary could be designed to know which slots in an instance
correspond to the unique index, and it could then automatically intern
objects in a hash table as it serializes them, and look them up when
reading them back in (this would be a good use of weak hash tables -- if
all other local references to the instance have been discarded, it doesn't
matter whether the reader returns a new object, as there's nothing to
compare EQL to).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Tim Bradshaw
Subject: Re: Session state in web applications
Date:
Message-ID: <nkjy9qxmunh.fsf@tfeb.org>
Kent M Pitman <······@world.std.com> writes:
>
> Perhaps they (either Java or CORBA or anything else that thinks
> serialization can work reliably) take as axiomatic the idea that
> serialization does or must work and consider that any data structure
> you make that cannot be serialized is the error.
Maybe they are even right, I'm not sure. A system which does not rely
on object identity can scale to platforms - like shared-nothing
machines - where object identity is hard to maintain. On the other
hand, at the platform level, shared-memory machines, which can
maintain identity at the this-points-to-that level, have pretty much
demolished non-shared-memory machines, so I guess *someone* cares.
Sometimes I think that Lisp people have a distorted view because we
use a lasnguage which is *so* good at dealing with enormous complex
datastructures, that we've been spoiled. After all everything is a
string...
--tim
Tim Bradshaw <···@tfeb.org> writes:
> I've always been terrified by this kind of thing. Java makes
> serialisation claims, and I really have now idea what it does. Either
> it does it wrong, or as far as I can see you need to keep something
> like an EQL hashtable of everything-you-have-ever-serialised and use
> that to maintain EQLness on the far side. Which is expensive.
I think that's exactly what they do. A lot of the work on Java's RMI
came from Modula-3 and in the paper at
http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-115.html
you'll find a description of how this works. At page 10 you'll find
the algorithm used to do this serializing (or pickling in Modula-3
terminology). Research report 116 describes the distributed garbage
collection that allows objects to be gc-ed after all references on all
servers are gone.
--
Lieven Marchand <···@wyrd.be>
Making laws appears to win votes. Enforcing them doesn't.
See Rule One. Roger Burton West in the monastery.
Tim Bradshaw <···@tfeb.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
>
> I suspect - like you perhaps - that object identity is not so much
> relied-on in some other languages. Perhaps this is because
> object-ownership issues are so bad in a non-GCd language that it's
> less painful to copy things all the time. Presumably this has
> persisted in java for cultural reasons...
>
> (a CORBA person is now going to explain how it solves all these
> problems at a stroke, I can feel it...)
>
I don't know if I'd call myself a "CORBA person", but, FWIW, I've
been using for a couple of years. My take is CORBA solves this
by not solving it; i.e. you don't actually serialize the object;
you just pass a _reference_ to an object to another process.
But there's still only 1 object�, in one image, somewhere, on 1
computer, which _is_ the object (the Servant, in CORBA terms).
There's this method is_equivalent (if memory serves right) that
you can call on any 2 corba references which pretty much means
what the lisp EQ means.
Or am I just adding to the confusion? :-)
� Yes, I know that one servant can be made to mimic the identity
of several corba objects, but that's just a distraction for this
argument.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
From: Tim Bradshaw
Subject: Re: Session state in web applications
Date:
Message-ID: <nkjbsnstrjv.fsf@tfeb.org>
Alain Picard <·······@optushome.com.au> writes:
> I don't know if I'd call myself a "CORBA person", but, FWIW, I've
> been using for a couple of years. My take is CORBA solves this
> by not solving it; i.e. you don't actually serialize the object;
> you just pass a _reference_ to an object to another process.
> But there's still only 1 object�, in one image, somewhere, on 1
> computer, which _is_ the object (the Servant, in CORBA terms).
So this is kind of shared-memory at the application level?
--tim
Alain Picard <·······@optushome.com.au> writes:
> I don't know if I'd call myself a "CORBA person", but, FWIW, I've
> been using for a couple of years. My take is CORBA solves this
> by not solving it; i.e. you don't actually serialize the object;
> you just pass a _reference_ to an object to another process.
> But there's still only 1 object�, in one image, somewhere, on 1
> computer, which _is_ the object (the Servant, in CORBA terms).
Good points, but ...
If the original discussion was about how to offload resources from one
machine to another, CORBA doesn't really do that, does it? The IOR has
a pointer to machine and port and process, or some such, no?
[Disclaimer: I've not used CORBA myself; I just took a several day
seminar in its concepts. I think I'm conversational in it, but please
do correct any confusions I might be displaying...]
I gather there is a migratable object substrate you can plug into CORBA
but... (1) does this require the server you're trying to free up to handle
forwarding service for this object? and (2) if you migrate the thing from
its normal home, you have to refer to all other CORBA objects it thought
were neighbors as remote handles, which might need migration, too, right?
(3) And objects which are not addressed by IOR are assumed by "something you
have to arrange for migration of", right? Which kind of begs the current
question, right? Not to mention that even if you did migrate it, it might
take as much network traffic to do that (CORBA being pretty network
heavyweight) as it would take to finish out the burdensome pending request
for HTTP service that you were trying to quickly offload... no?
> There's this method is_equivalent (if memory serves right) that
> you can call on any 2 corba references which pretty much means
> what the lisp EQ means.
But CORBA does not forbid machine-native references within the actual
workerbee instance of the agent, right? So it still is up against the
same question of "can this process migrate" unless it has built its
entire programming framework on corba objects, which I had understood to be
generally thought by CORBA users to be computationally too much overhead
for anyone to do.
>>>>> "kmp" == Kent M Pitman <······@world.std.com> writes:
kmp> If the original discussion was about how to offload resources
kmp> from one machine to another, CORBA doesn't really do that, does
kmp> it? The IOR has a pointer to machine and port and process, or
kmp> some such, no?
you can do simple load balancing at the time a client aquires the IOR,
from a naming or trading service. Once an IOR has been aquired, an
overloaded server can also redirect requests to another machine+port
using a LOCATION_FORWARD message. The tricky bit is the state transfer
between servants, which is done by the programmer (possibly assisted
by the persistent state service).
kmp> But CORBA does not forbid machine-native references within the
kmp> actual workerbee instance of the agent, right? So it still is
kmp> up against the same question of "can this process migrate"
sure, CORBA doesn't magically make object migration transparent; the
degree of explicit programmer support will depend on the programming
language and operating system. In Lisp for example, how do you
serialize network connections? Are threads which were waiting on
semaphores restored correctly?
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Kent M Pitman <······@world.std.com> writes:
> If the original discussion was about how to offload resources from one
> machine to another, CORBA doesn't really do that, does it?
To my knowledge, it does not.
> The IOR has
> a pointer to machine and port and process, or some such, no?
Correct.
I think a very common paradigm is that a CORBA object really
reflects some state in a database somewhere. So in overload
conditions, you might forward the request (as some other poster
mentioned) and the other server would be able to instantiate
a "copy" of the servant which pretends to have (or really has, depending
on your viewpoint) the same identity as the one you were trying
to talk to.
Which just punts on the hard issue: how do you replicate and
load share the database? (Answer: you let your vendor do it).
To recapitulate: Lisp doesn't do proper serialization (with object
identity) because it's too hard; and CORBA doesn't do it either.
And I suspect, Kent, that your intuition is correct, Java (and Python,
actually) people *think* they do proper serialization because they're
not used to thinking of the identity of objects (the EQness) as lisp
people are.
Maybe "lisp provides EQ", "Java only gives you EQUALP" ?
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> To recapitulate: Lisp doesn't do proper serialization (with object
> identity) because it's too hard; and CORBA doesn't do it either.
> And I suspect, Kent, that your intuition is correct, Java (and Python,
> actually) people *think* they do proper serialization because they're
> not used to thinking of the identity of objects (the EQness) as lisp
> people are.
>
> Maybe "lisp provides EQ", "Java only gives you EQUALP" ?
I think it's subtler than that.
Obviously Java passes pointers, even tagged ones, when it does
function call. It's got EQ. However, there's probably something in
the pain of type declaring that causes it not to be as densely
interconnected as Lisp is, and this probably results in
correspondingly less work in figuring out what to serialize. I bet it
causes them to typically hold onto one "big" object with lots of parts
rather than a lot of little objects, so when they seralize it's fewer
things you have to make sure handle a "seralize" message.
It may also be that Java typically results in smaller and less complex
programs than Lisp does, giving up on the larger ones or quietly giving
up on serialization as a core technology of the larger ones.
Getting stats like any of these would be tough.
>>>>> "tb" == Tim Bradshaw <···@tfeb.org> writes:
>>>>> "ap" == Alain Picard <·······@optushome.com.au> writes:
ap> My take is CORBA solves this by not solving it; i.e. you don't
ap> actually serialize the object; you just pass a _reference_ to an
ap> object to another process. But there's still only 1 object�, in
ap> one image, somewhere, on 1 computer, which _is_ the object (the
ap> Servant, in CORBA terms).
tb> So this is kind of shared-memory at the application level?
at the middleware level, rather. Apart from latency and failure
semantics, the fact that the invoked object is remote rather than
local is transparent to the application level.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
From: Tim Bradshaw
Subject: Re: Session state in web applications
Date:
Message-ID: <nkj8ziwgtnd.fsf@tfeb.org>
Eric Marsden <········@mail.dotcom.fr> writes:
>
> at the middleware level, rather. Apart from latency and failure
> semantics, the fact that the invoked object is remote rather than
> local is transparent to the application level.
>
Sorry, I meant `application level' as meaning `not OS + hardware'.
--tim
On Tue, 12 Jun 2001 13:31:03 GMT, Kent M Pitman <······@world.std.com>
wrote:
> Anything strikes *me* as hard to serialize because Lisp is a language that
> cares about identity. Just because you can make a new object doesn't mean
Hasn't Lisp been doing it right all the time with image dumping? :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Tim Bradshaw
Subject: Re: Session state in web applications
Date:
Message-ID: <nkjy9qwn0lm.fsf@tfeb.org>
Paolo Amoroso <·······@mclink.it> writes:
>
> Hasn't Lisp been doing it right all the time with image dumping? :)
>
But image dumping is serialising the whole world, which is just what
you're trying to avoid when serialising a single object.
--tim
"Joel Ray Holveck" <·····@juniper.net> wrote in message
····················@sindri.juniper.net...
> >> Session states in web applications are essentially continuations.
> >> See the paper
> >> http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.pdf.gz
> > Graham's session-state-as-closures technique is a cool hack, but I
wonder
> > how scalable it is. It forces a remote user to be served by the same
> > Lisp image (on the same machine, obviously) on every transaction. While
> > it's desirable to do that for caching reasons, etc., it's not great to
> > rely on that mode of operation: load balancing, hardware failure,
> > and network problems/instability, to name a few factors, all conspire
> > against it.
>
> Is there any reason that continuations couldn't be made serializable?
May be I am missing the point but I don't see why you want to do that.
The load balancing can send the requests related to one session always to
the same computer. Hardware failures are possible but with a low
probability. If you really care about them, you can save the session state
to a database to improve reliability (you need to secure the database in
this case),. In this case you only need to reload a session state in case of
failure, not for every request. The load balancing can be driven by the Lisp
servers so that to be optimized for the application.
Why would such a system have problems even with millions of hits/day. It
will still be much faster than Java servlets, PHP, ASP, .NET, etc. and much
more reliable than the same ones plus C/C++, ASM etc...
Marc
In article <···············@world.std.com>, Kent M Pitman wrote:
> ...
>> Good reason to post these messages, dont you think ?
>
>No. Absolutely not. This is like proposing to someone on TV. It may be
>very romantic if the person wants to say "yes" but you'd better be darned
>sure that's what they plan to say before you do it. Otherwise, it is a huge
>public embarrassment that you have no right to turn on them because everyone
>gets to watch the person being asked the question give a disappointing answer
>and that person feels like a jerk.
i took the post that started the trend more as an indication that there is
a pretty high unsatisfied demand for the book, and that people turn to
desparate measures to get their hands on a copy. the way he expressed it
certainly did *not* sound like he requested a freebie
> ...
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
From: Tim Bradshaw
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <nkjn18dr1ba.fsf@tfeb.org>
··@paradise.nirvananet (Hartmann Schaffer) writes:
> i took the post that started the trend more as an indication that there is
> a pretty high unsatisfied demand for the book, and that people turn to
> desparate measures to get their hands on a copy. the way he expressed it
> certainly did *not* sound like he requested a freebie
>
Has anyone actually tried ringing PH and asking them what the
prospects for a reprint are? That would seem orders of magnitude
better than oosting articles in newsgroups which PH editors are
unlikely to read.
--tim
--
Remove obvious stuff to e-mail me.
Bob Bane
Tim Bradshaw wrote:
>
> Has anyone actually tried ringing PH and asking them what the
> prospects for a reprint are? That would seem orders of magnitude
> better than oosting articles in newsgroups which PH editors are
> unlikely to read.
>
No, but I did take a look at http://www.paulgraham.com/faq.html:
Where can I get a copy of On Lisp?
Unfortunately it is out of print. I've heard there are some copies left
at
amazon.co.uk, but they are not likely to last long. If you like I can
put you
on this page, which has led to some people getting copies. Copies also
sometimes come up for sale at eBay.
I am in the process of getting the rights back from the publishers.
Then
I'll either set up some kind of print on demand arrangement, or just
put
it online.
Also, see http://www.paulgraham.com/wantonlisp.html
Graham is not unaware of the problem.
In article <·················@removeme.gst.com>, Bob Bane wrote:
>
> --
> Remove obvious stuff to e-mail me.
> Bob Bane
> Tim Bradshaw wrote:
> >
> > Has anyone actually tried ringing PH and asking them what the
> > prospects for a reprint are? That would seem orders of magnitude
> > better than oosting articles in newsgroups which PH editors are
> > unlikely to read.
> >
> No, but I did take a look at http://www.paulgraham.com/faq.html:
>
> Where can I get a copy of On Lisp?
>
> Unfortunately it is out of print. I've heard there are some copies left
> at
> amazon.co.uk, but they are not likely to last long. If you like I can
> put you
> on this page, which has led to some people getting copies. Copies also
> sometimes come up for sale at eBay.
>
> I am in the process of getting the rights back from the publishers.
> Then
> I'll either set up some kind of print on demand arrangement, or just
> put
> it online.
>
> Also, see http://www.paulgraham.com/wantonlisp.html
>
> Graham is not unaware of the problem.
I did call PH when I was looking for on lisp, right around when it
started to be seriusly hard to find. They told me that the plates
were distroyed and they had no plans for a second edition. I did
finaly get a copy thanks to Mr Graham's wantonlisp.html page and I
would like to thank him publicly for providing the service. Remember
lisp is a small community and a small goup of loud vocal people does
not buy many books. The first production run lasted for over 10 years
and this is not good from the publishers point of view when he has
other books that sell out in 1-2 years, quite probably with larger
print runs. The fact that they are useless in 3 years max from the
inital print run is a good thing, he gets to sell more books. I have
heard some rumors about book on demand publishing becoming practical.
What would be cool for lisp would be a publisher, like Dover press,
that would find a profitable bussness by buying the rites to books
that will otherwise never again see the light of day and set up a web
site where you could order these books and get them printed as needed.
marc
raj <········@optushome.com.au> writes:
>>The apparent thirst on this newsgroup for pursuing a "gimme free
>>stuff" seriously irks me.
> There was a post from a person who offered to buy the tex or
> postscript file from PG but recieved no reply.
.. And is Graham under obligation to respond to every email he
receives?
>>It might be, indeed, that he just doesn't care about the revenue from
>>the book any more
> That is likely. After all, he did sell his company for 40 million $
> to Yahoo...
I'd think the revenue wouldn't be of _too_ much importance, but would
find it remarkable if this were the primary reason that he wrote the
books in the first place.
Most of the people that produce the really _great_ technical books
wrote them in order to attain riches. I'm quite sure Donald Knuth did
_not_ write TAOCP just to receive millions in royalties from Addison
Wesley.
The value of producing a really good technical book comes more from
the "fame" than from the "fortune." Writers of such works generally
get paid for doing something else, such as being a professor.
Having a famous book very likely makes it easier to get larger
research grants, and better grad students. Neither of those are the
same thing as royalties.
This is a longwinded way of suggesting that it would be a bit surprising
if Graham was _solely_ motivated by personal greed. I'm sure he wouldn't
turn away someone offering him wheelbarrows full of money, but as VC has
gotten tight again, I expect that there are few wheelbarrows out there.
>>It migth be that he's very busy and plans to republish the book when
>>he gets the chance.
> Good reason to post these messages, dont you think ?
Not necessarily.
>>But it's his book, and his right to do with it as he wishes. And
>>meanwhile, there are others with books that need buying to support
>>other authors.
I'm not clear on which ones are actually still in print. Norvig's
book probably is, but there aren't many others.
>>You may, by the way, think that a publisher is just a nameless entity
>>that is profiteering off of our community. But I *want* publishers to
>>make as much money off of our community's books as they can
> Hmm.... Brain Research ( published by Springer Verlag ) is
> currently 17,000 $ for a one year subscription. Guess which journal
> our library will not be subscribing to this year....
Probably so. I can't _imagine_ what they'd have in there that would
justify a $17K subscription price.
On the other hand, if you're running a neurological research lab,
there might well be something found there that can't be found anywhere
else that would justify the price. It certainly doesn't sound like a
journal for the layperson...
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/resume.html
Rules of the Evil Overlord #57. "Before employing any captured
artifacts or machinery, I will carefully read the owner's manual."
<http://www.eviloverlord.com/>
········@hex.net wrote, without proofing well enough...
> Most of the people that produce the really _great_ technical books
> wrote them in order to attain riches. I'm quite sure Donald Knuth
> did _not_ write TAOCP just to receive millions in royalties from
> Addison Wesley.
Oops. That should read...
Most of the people that produce the really _great_ technical books
_DID NOT_ write them in order to attain riches....
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/resume.html
Rules of the Evil Overlord #57. "Before employing any captured
artifacts or machinery, I will carefully read the owner's manual."
<http://www.eviloverlord.com/>
From: Janis Dzerins
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <87n18e67a6.fsf@asaka.latnet.lv>
raj <········@optushome.com.au> writes:
> >The apparent thirst on this newsgroup for pursuing a "gimme free stuff"
> >seriously irks me.
>
> There was a post from a person who offered to buy the tex or
> postscript file from PG but recieved no reply.
And do you also know why it was a *post* instead of a private mail?
> >It might be, indeed, that he just doesn't care about the revenue from
> >the book any more
>
> That is likely.
> After all, he did sell his company for 40 million $ to Yahoo....
Yeah. Looks like you like counting someone else's money. That does not
change anything, does it?
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
On 15 May 2001 17:01:05 +0300, Janis Dzerins <·····@latnet.lv> wrote:
>> There was a post from a person who offered to buy the tex or
>> postscript file from PG but recieved no reply.
>
>And do you also know why it was a *post* instead of a private mail?
When I last checked, telepathy was not listed on my cv.
>> >It might be, indeed, that he just doesn't care about the revenue from
>> >the book any more
>> That is likely.
>> After all, he did sell his company for 40 million $ to Yahoo....
>Yeah. Looks like you like counting someone else's money.
No, I am providing objective data that corroborates a statement made
by another person.
Perhaps you need a new parser....
In article <··································@4ax.com>, raj wrote:
>On 15 May 2001 17:01:05 +0300, Janis Dzerins <·····@latnet.lv> wrote:
>
>>> There was a post from a person who offered to buy the tex or
>>> postscript file from PG but recieved no reply.
>>
>>And do you also know why it was a *post* instead of a private mail?
>
>When I last checked, telepathy was not listed on my cv.
iirc, the poster mentioned that he emailed paul graham with this offer/
request and didn't receive a reply. he didn't post the offer
> ...
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
From: Janis Dzerins
Subject: Re: [NOT] Re: To Paul Graham: Please put your books online.
Date:
Message-ID: <87itj261ma.fsf@asaka.latnet.lv>
raj <········@optushome.com.au> writes:
> On 15 May 2001 17:01:05 +0300, Janis Dzerins <·····@latnet.lv> wrote:
>
> >> There was a post from a person who offered to buy the tex or
> >> postscript file from PG but recieved no reply.
> >
> >And do you also know why it was a *post* instead of a private mail?
>
> When I last checked, telepathy was not listed on my cv.
So how do you know that the person did not receive any reply?
> >> >It might be, indeed, that he just doesn't care about the revenue from
> >> >the book any more
> >> That is likely.
> >> After all, he did sell his company for 40 million $ to Yahoo....
>
> >Yeah. Looks like you like counting someone else's money.
>
> No, I am providing objective data that corroborates a statement made
> by another person.
Your objective data is invalid.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.