On Sat, 3 Mar 2012 17:56:06 -0500 Joe Bogner <[email protected]> wrote:
> Hi José - > > I've been thoroughly impressed with everything I've seen from you and > even more so if you're a student. Wow! > > Related to your proposal below, if I can replay back what I am > understanding, it sounds like there are three aspects to it: > > 1.) A more robust interface between a web server and a picolisp app. > Something that can work in a variety of situations (e.g.VPS or > dedicated hosting). This should enable more adoption of picolisp as a > language for building web applicationss. > > [Sidenote: I've used your SCGI.l with nginx with and it would benefit > others to document how that could work] > Yes exactly, a simple and "hackable" way to connect to most common web server interfaces used nowadays. > 2.) A routing framework (does this follow the REST framework > discussions we've had on IRC?) to simplify web app development - again > it seems like you are close here based on what I've seen in scgi.l > Yes, by default I'd like to implement a simple RESTful resource dispatcher, but it would be just the default, you can override the handler earlier in the request and still benefit from the work done in the "backends" while implementing some oddball URL schema in the most comfortable way. That could be a quick and "simple" way to gradually port the existing GUI framework to all those servers without rewriting the whole app system to be restful. > 3.) Provide some of the same functionality as XHTML without tying it > to the session IDs. In other words, enable the general purpose GUI > framework to be agnostic of the 'server' it's running in > That too, I'd like to eliminate deep dependencies between modules, I'd rather make a simple module that then can be easily "monkey patched" by a more complex app than having it the other way around. I know that hurts startup time, but unless you are using the "app as cgi script" model it doesn't matter, and even then, it shouldn't be hard to preprocess the sources to generate a more optimized "compiled" script, the same way javascript files are being minified nowadays. > I think these are all wonderful ideas. If I was sitting on the > committee evaluating proposals for the GSoC I would be evaluating > projects based on their ability to have a broad impact or solves an > unsolved problem. Since picoLisp is fairly niche, I like that what > you're suggesting could open it up to more developers. I am no expert > in this area though. I am not sure how this would stand out against > framework XYZ aiming for broader appeal. > > I spent a minute looking for some more context on GSoC related to > languages. I found a retrospective on haskell: > http://www.gwern.net/Haskell%20Summer%20of%20Code > > I guess for someone with no knowledge of picoLisp, as it relates to > your proposal, why is picoLisp a good choice for web development? What > would the successful completion of the proposal enable? I have some > perspective but would be interested in hearing what you think. > One thing I love about picolisp is it's interactivity, I can interact with a running app using the repl (and the wonderful 'edit function). The equivalence of code and data and dynamic binding help a lot to alter the system as it's running to try out new things with a very quick turnaround time. And still, despite the great flexibility it also offers very competitive speed if you compare it to other common languages used for the web. The whole system is also simple enough to be able to learn deep stuff about it's internals and code minding them instead of treating it like a black box behind a truckload of specs. Other very positive point for picolisp is it's code compactness, the built in functions are simple building blocks that can achieve really powerful and diverse behaviors combining them in clever ways, much like the UNIX core utils. Another relevant good point for picolisp used in this scenario is it's database system. Sadly it's not as well documented as it deserves, but every day I find out new things about it. (Documenting it would be a great project, but GSoC favors code over documentation, sadly.) > Thanks for sharing it! > Joe > > [snipped bottom post] -José -- UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe
