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] 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 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 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. Thanks for sharing it! Joe 2012/3/3 José Romero <jose.cyb...@gmail.com>: > On Sat, 03 Mar 2012 21:10:25 +0100 > Thorsten <quintf...@googlemail.com> wrote: > >> Alexander Burger <a...@software-lab.de> writes: >> >> Hi List, >> >> > On Mon, Feb 27, 2012 at 01:40:16PM +0100, Thorsten wrote: >> >> We prepared a GSoC 2012 page in the PicoLisp wiki >> >> (http://picolisp.com/5000/!wiki?gsoc), where you can find more >> >> information. >> >> ... >> >> For now (till 2012-03-09) the most important task is to collect >> >> ideas and find out who would like to be a mentor for his (or other >> >> peoples) project ideas. Then, if PicoLisp is accepted by Google, >> >> we need to spread the word and make students apply for a project. >> >> >> >> Any thoughts or ideas how to make the PicoLisp application for the >> >> GSoC 2012 a success are welcome. >> >> I would suggest to add at least 2 or 3 more project ideas to the ideas >> page (http://picolisp.com/5000/!wiki?ideasPage) to raise the odds of >> PicoLisp being accepted as mentoring organisation. >> >> The best case would be if anybody is interested to participate as a >> student and has a project idea (and a possible mentor in mind). >> However, if you would like to see some new feature in PicoLisp and to >> mentor the related project, it would be very helpfull too. >> >> A third (viable) option is to think about a project idea that is >> beneficial for the PicoLisp community and doesn't require special >> background (domain) knowledge from a (potential) mentor, but might be >> interesting for students in general. That way, you can propose an idea >> without being the student or mentor for that proposal. >> >> As an example, I would propose the project "Build a web-shop for >> PicoLisp". Would that make sense? Any other ideas? >> >> If somebody has an idea but doesn't want to get involved with the >> wiki, he can just post it here on the list, I put it on the wiki >> then. >> >> Thanks > > If I can make it to participate as a student I'd like to make a more > generic and portable web framework (in the sense of being able to deploy > it in more kinds of servers than a dedicated/VPS with permission to run > a server on a public port) Right now I have some work done in that > direction with my "scgi.l" simple framework that is capable of running > as a SCGI service, a CGI script and writing an HTTP backend it can also > run as a standalone server (or actually, any protocol that has a > CGI/HTTP-like interface can be adapted writing a backend) sharing most > of the code (I have some code for that but i haven't published it yet > because it's not complete/useful for anyone else than me at the > moment). > > I have a formed idea for the "low level" design of the framework, as > the internal protocol all backends "dump into" the app using a > consistent interface (a set of global variables and functions). > > If you are allowed to run persistent processes in your server you > would have at least these options for connecting the web application > to the web (or a caching reverse proxy). > > +---+ +--------+ +------+----------+------------------------+ > | | <->| Web |<->| SCGI <> <> | > | I | | Server | +------+ <> | > | n | +--------+ | <> | > | t | ^ +-----+ +-----+ Common <> Web | > | e | '->| CGI |<->| PGI <> <> | > | r | +-----+ +-----+ Module <> Application | > | n | | <> | > | e | +------+ <> | > | t |<--------------->| HTTP <> <> | > | | +-----------------+------------------------+ > +---+ > > The "PGI" (Picolisp Gateway Interface) backend is just thin glue to > allow a very simple CGI script to be able to "tunnel" a request to the > running picolisp server, to do it "properly" picolisp should be > provided with unix domain socket support so that it's not necessary > for the server to take a random high port and to ensure the same > privilege separation provided by the filesystem in the standard web > server setup (owners, users, chroots). The other backends are pretty > self explanatory, the functions defined in the common module should be > made in a way that the application can use special features in the > backend (for example X-Sendfile headers) falling back to emulating > them with picolisp for backends that do not support it. > > If you are not allowed to run persistent processes you can still use > the framework (say, a very low traffic site, or you are just doing > tests on a shared host before investing on a bigger server) by > wrapping the whole thing around a CGI script, without changing any > more code downstream. > > The things left to design is which would be the desirable feature set > the common module should have and how they should be implemented to > get the best efficiency and compatibility. So far I have implemented a > minimal feature set for some simple services I needed (right now > running with the GCI+PGI): > > - A simple url pattern based dispatcher: the default implementation > of 'req-handler tries to match the incoming URL with a list of > patterns and executes the corresponding code for the request > (inspired by the design of Flask http://flask.pocoo.org/) > - Some lazy functions for decoding the querystring and postdata into > alists. > - A kludgy "compatibility layer" to be able to reuse part of xhtml.l > > Things left to design are how to keep track of sessions. Picolisp's > persistent process system is simple and very efficient, but there > should be a filesystem fallback for CGI. It would be also very > desirable to make the existing GUI framework work with it. I'd really > appreciate you input :) > > Thanks, > José > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
