Re: [Mod-guile-devel] guile-handler

[rm]

On Mon, Jul 29, 2002 at 01:29:31PM -0400, Dale P. Smith wrote:
> address@hidden wrote:
> [...]
> > How should we handle output to the client?
> > 
> > - a transparent redirect (current-output-port will
> >   point to an apache port that uses the apache api to
> >   send data to the client). This is an aproach many
> >   embeded script interpreters have:
> >     (display (string-append "<h1>" (dynamic-stuff) "</h1>"))
> >   will do 'the right thing'.
> 
> I've currently implemented this two ways.  The current-output-port is
> just a string port that gets sent to the client when the request is
> finished.  The second way is to use an apache port.  This sends the
> output directly to the client with each write or display.

Yes, i saw this. I used your code for my mg_guile_handler, it seems to
work fine so far. The response latency really is getting nice now ;-)

> The problem with the second way, is that good error reports are
> difficult to send to the client.

Yes, but that's allways the case sending dynamic output - once the header
is out you have no way to modify the return code. I can live with that.
The problem i see with the string buffer approach: the client won't see
anything at all until _all_ content is out. Recent browers do a pretty fine
job in renering partial pages. You loose apache's buffering/chunking.
Also, if your result is getting big, i fear that this might push memory
requirements unneccessarily.

> > - Have special functions that send data to the client:
> > 
> >   (define (handler request)
> >     ...
> >     (send-data request "<h1>" (dynamic-stuff) "</h1>")
> >     ...)
> 
> What should be done with stdout? (or current-output-port in scheme terms).

Have it go wherever it want's to :-) After a lot of web programming i'm actually
a bit nervous about default redirects (logs full of perl's "print of undef 
variable"
and libraries that insist on sending error messages to stdout ...).


> > - Use 'goops' -- make 'display' a generic that can deal with
> >   a request_rec as it's second parameter:
> > 
> >   (define (handler request)
> >      ...
> >      (display (string-append "<h1>" (dynamic-stuff) "</h1>") request) 
> >      ...)
> >  Of course, goop's C-api is pretty much undocumented ...
> 
> Actually, it doesn't really exist yet.  I wanted to use goops for
> accessing the request_rec and other structures, but the lack of a C
> interface pretty much made it impossible.

Ah, i feel your pain. Goops, so close to us but yet so far ...
Hmm, i was thinking of making at least the req_record a goops object
from the guile side. 

> I think the "current-output-port goes to the client" is best.  Are there
> any advantages to the other methods?

I guess for now i stick with that -- after all, the user base seems small
enough to tolerate API changes.

 Ralf

> 
> -Dale
> 
> -- 
> Dale P. Smith
> Senior Systems Consultant,      | Treasurer,
> Altus Technologies Corporation  | Cleveland Linux Users Group
> address@hidden            | http://cleveland.lug.net
> 440-746-9000 x339               |
> 
> _______________________________________________
> Mod-guile-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/mod-guile-devel