Paul, could you enlighten us how well does this type of development (Lisp macro/closure based) integrate with JS and Ajax? I'm interested in asynchronicity of the Ajax... Ruby and Python with Protoype and Scriptaculous make this very easy indeed...
Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
21–23 of 23 posts
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#22Earlier quoted context omitted.
For calls that don't need to know about more state than their arguments, we just use an ordinary url with arguments. Otherwise we make a closure and store it in a hash table in memory, and make the url be x?fnid= where the argument is the hash key. When an http request comes in, we call the corresponding closure. Sometimes what to do next after following a link generated by the closure (e.g. what to do after logging…
What extra data is in the closure for "reply" that means it isn't a simple URL? Is it just what to do after the reply is complete, i.e. what post to return to viewing? Is there a reason this isn't taken from the Referer instead? I guess this technique doesn't scale too well unless the hash table is either shared across servers or a user is kept on one server, which then causes problems of its own. I'm guessing 20,000…
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#23Earlier quoted context omitted.
What extra data is in the closure for "reply" that means it isn't a simple URL? Is it just what to do after the reply is complete, i.e. what post to return to viewing? Is there a reason this isn't taken from the Referer instead? I guess this technique doesn't scale too well unless the hash table is either shared across servers or a user is kept on one server, which then causes problems of its own. I'm guessing 20,000…
What particular problems are caused by the user being kept on one server?