On Fri, Jan 2, 2009 at 7:54 PM, Derick Eddington <[email protected]> wrote: > > 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 > ---------------------------------------------------------------- > >
Not quite the answer I was hoping for, I considered implementing my own "fcgi-port" but then having to reimplement all the built-in port support didn't seem reasonable. Only thing I can think of right now is to create my own "flush" which would do a flush-output-port and write the internal buffer to the connection and then provide that as a parameter to the request handler, not pretty but it should work. Thanks, /Patrik /Patrik
