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?subject=Unsubscribe
