you do not have to answer these promptly.
please take care of your flu first!
John Hinsdale wrote:
> On Thu, Jun 18, 2009 at 02:25:33PM -0400, Sam Steingold wrote:
>> 1. why do you need fcgi_getenv and fcgi_env? what's wrong with EXT:GETENV?
>> 2. why do you need fcgi_write_stdout, fcgi_write_stderr, read_stdio? what's
>> wrong with READ/WRITE-BYTE/CHAR-SEQUENCE on *STANDARD-INPUT/OUTPUT*?
> The idea behind FastCGI is that it "multiplexes" all the channels
> needed for old-time CGI's onto a socket stream (this done by the Web
> server) and provides APIs for those things to the process launched by
> the Web server. These "channels" are: env. vars, stdin, stdout and
> stderr. They cannot be got from the FastCGI process (which is a
> long-running process), but are rather fed in from the Web server,
> which communicates the data over a socket to the FastCGI process.
what I was trying to say was that
1. the code in fastcgi_wrappers.c for env var access seems to be compatible
with the code in misc.d for GETENV; are you sure that (FASTCGI:GETENV "FOO") is
different from (EXT:GETENV "FOO") and (FASTCGI:ENV) is different from (EXT:GETENV)?
2. in C, stdio is coupled to FDs 0,1,2, so are you sure that your i/o is
functionally different from the lisp i/o? i.e., if you replace (write-stdout
data) with (write-char-sequence data *standatd-output*), does it still work?
this should be faster and more robust!
> See here for how it works:
it looks like there is much more stuff there than the module exports at this
>> 3. why do you need hexify & hex-to-byte-array? why not pass around byte
>> vectors as is?
> I vaguely recall doing this so I could use the C-STRING
> (null-terminated string) type in the FFI, even w/ binary data. I
> agree it is a hack and adds overhead. I can revisit making it work
> directly w/ binary data.
I think using write-byte-sequence is what you are looking for.
Get well soon!