On Sat, 3 Mar 2012 17:56:06 -0500
Joe Bogner <joebog...@gmail.com> 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:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to