On Fri, 2009-01-02 at 15:32 +0100, Patrik Husfloen wrote: > Hello, > > I've been working on a Fast CGI [1] library for Ikarus (and other R6 > compliant schemes?) in my spare time, and today I served my first > successful request! :) > > (define (responder-test flags params stdin stdout stderr) > (let* ([utf8 (make-transcoder 'utf-8-codec)] > [writer (transcoded-port stdout utf8)]) > (put-string writer "Content-Type: text/html\r\n\r\n<html>HELLO > WORLD</html>\r\n") > 0)) > > It's not much at the moment, and the stdout and stderr ports are > pretty broken, and that brings me to my questions. > > I'm currently using make-custom-binary-output-port to create ports for > stdout and stderr and because I want to support multiplexed > connections over the fcgi connection the port has its own buffer that > it writes to, when a threshold is reached (or close is called) it's > written to the socket, but I would also like detect when > "flush-output-buffer" is called, so I can force the buffered data to > be written to the fcgi connection. > > The R6RS spec mentions buffer-modes on ports, and says that each port > has one of three buffer modes: "none", "line" , "block", and it > mentions how to check the buffer mode on a port, but I can't see any > mention on how to set it, and also, if you can set it, can I implement > my own custom buffer mode, or would I have to set it to "none" and > implement the buffering in the port? Or can you change the properties > of the "block" buffer mode on a per port basis? > > But the port returned by make-custom-binary-output-port has buffer > mode "block". Which means that when I call flush-output-port on > stdout, all I get is whatever data the port buffer has buffered, and > not an indication that "flush" was called. I was hoping that with > buffer-mode "none" I could detect a "flush" as a zero byte write and > write whatever I have in my buffer to the socket, but that might be > wishful thinking, maybe there's an easier way to accomplish what I > want?
I think you've come across another flaw in R6RS. I can't find anything in the report describing how custom ports relate to buffering or flushing. I don't think you can even implement your own flush-output-port that would work on your custom ports because R6RS gives you no way to recognize your custom ports nor perform extended operations on them (unless you implement a hashtable registry and deal with that mutable state, which seems like the wrong way). I've already been wondering if custom ports should instead be done by extending standard port record types. This way you can recognize them, access their extended fields, and perform extended operations on them. The base port type would have a field for the buffer mode, and the base output port type would have a field for a flush! procedure, and the whole design would have whatever else it takes to make custom ports usable and fit with the rest of the standard. Another rant: R6RS has output-port-buffer-mode but not input-port-buffer-mode even though both output and input ports have buffer modes. I've got to say, the more I learn about R6RS the more I think it needs to be revised ASAP. -- : Derick ----------------------------------------------------------------
