chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Choosing a programming language for a web project


From: Graham Fawcett
Subject: Re: [Chicken-users] Choosing a programming language for a web project
Date: Tue, 2 Oct 2007 13:44:11 -0400

Hi Michele,

On 10/2/07, Michele Simionato <address@hidden> wrote:
> I will just add a relevant link:
> http://wsgi.org/wsgi
>
> See also the WSGI 2.0 specification, where the minimal application is 
> something
> like
>
> def app(environ):
>     return '200 OK', [('Content-type', 'text/plain')], ['Hello world']

Thanks, that's clearer than my explanation.

> > So, in my WSGI-like interface for Chicken, a request/response pair is
> > a 4-tuple, (incoming-request-headers, current-input-port,
> > current-output-port, outgoing-response-headers). The application
> > framework is represented by a single procedure that takes a 4-tuple as
> > an argument, and returns no value. Upon an inbound request, the
> > protocol side calls the procedure, and afterward it processes the
> > outbound headers and output string-port.

> I am not convinced by the current-output-port. In WSGI you return an
> iterator over strings (say a list) so that middleware can further process it.
> Post-processing the current-output-port looks more cumbersome.

That's fair, though perhaps it depends on what type of post-processing
the middleware might do? In some cases, might processing the entire
output as a whole string be more effective? I don't have real
experience with WSGI middleware, so I can only speculate.

A custom output-port could be used to provide iteration: writing a
string to the port would invoke the continuation of the middleware,
which would process (or queue) that piece, and then return to the
application. From the application perspective, it would be
transparent: just writing to the port generates the piecewise feed for
the middleware. One can imagine the application and middleware
components as a chain of generators, with the protocol-handler as the
ultimate consumer. I suppose that's the WSGI style.

Since my preferred approach (just print it!) could be modeled in your
preferred one (iterator of strings), I am going to sit on the fence on
this one!

> Just my 0.02c,

At least a dollar's worth. ;-)

G




reply via email to

[Prev in Thread] Current Thread [Next in Thread]