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

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
 - 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 :)

UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to