This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sources of kawa documentation


Hoehle, Joerg-Cyril wrote:
> I knew about it, but with "Functions for generating HTTP responses", I did not see how to output that stuff to something. It says:
> "response-header key value
>    Create the response header key: value in the HTTP response.
>  [...] when you actually "print" its value to the response output stream. 
> Where is that HTTP response object and associated output stream that's being talked about?

It's hidden inside the servlet state.  When you compile a
KRL/BRL/Scheme/XQuery program with the --servlet flag,
then the result of the top-level expression becomes the
HTTP response.

I added this to the manual:

Writing web-server-side Kawa scripts
====================================

    You can compile a Kawa program (written in any supported Kawa
language, including Scheme, BRL, KRL, or XQuery), and run it as either
servlet engine (using a web server that supports servlets), or as a
"CGI script" on most web servers.

    In either case, the result of evaluating the top-level expressions
becomes the HTTP response that the servlet sends back to the browser.
The result is typically an HTML/XML element code object; Kawa will
automatically format the result as appropriate for the type.  The
initial result values may be special "response header values", as
created by the `response-header' function.  Kawa will use the response
header values to set various required and optional fields of the HTTP
response.  Note that `response-header' does not actually do anything
until it is "printed" to the standard output.  Note also that if a
`"Content-Type"' response value is printed that controls the formatting
of the following non-response-header values.

> Nice, but hopefully as chains inside Scheme, not as separate UNIX programs?

Of course.  That is the point of Consumers.  The tricky part making
this is efficient as I can make it.

> I hope it will. In Common Lisp, I'm missing the flexibility that I have
 > Python of defining arbitrary classes that implement parts of the stream
 > protocol, e.g. only write(), read(), read-line() etc. as needed.

Well, you can of course use define-simple-class to write a class that
extends gnu.mapping.OutPort.  At least in principle!

> BTW, I'll try to proof-read kawa.texinfo and edit typos as time allows.
> Hmm, didn't ispell provide an easy checker for TeX(info?) at some time?

Mechanical spell-checkers do catch soem mistakes, but they don't
substitute for proof-reading.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]