GT.M/FastCGI

Sean Woods

unread,

Nov 16, 2010, 5:16:49 PM11/16/10

to

For some time I've envisioned a FastCGI/GT.M interface. I've looked
over the
alternatives (namely the M/* apps from M/Gateway) and while they look
great,
I've had an itch to implement something a bit closer to traditional
CGI.

Recently I hacked an interface together using call-ins. It works, but
is quirky
enough to render it unusable:

1. When I write using printf() before the call-in, I see the output as
expected in the browser.

2. When I write using WRITE within the M routine, the output appears
in
the apache error log. The command WRITE $IO shows 0. On my plain CGI
version it shows 1 (which makes sense given that its writing to
stdout),
so I think something may be amiss here.

3. Subsequent calls to printf() appear to send the string "nowhere."
It
doesn't appear in the browser or in the error log. (I'm thinking if I
fix #2 this will follow.)

The FastCGI library I'm using (the one available from the website)
fiddles with std{in,out,err} to maintain compatibility with old CGI
programs. This works splendidly as long as I stay in C, but GT.M
appears to manipulate the devices differently (perhaps when setting up
$P, I don't know). I feel like if I get this one last detail working,
I'd have a neat little library.

Anyways, I'd appreciate any insight into how I might make this work.

Thanks,
Sean

rtweed

unread,

Nov 16, 2010, 6:06:18 PM11/16/10

to

>I've had an itch to implement something a bit closer to traditional
>CGI.

Why?

Rob

K.S. Bhaskar

unread,

Nov 17, 2010, 3:13:30 PM11/17/10

to

On Nov 16, 5:16 pm, Sean Woods <woodsy...@gmail.com> wrote:
> For some time I've envisioned a FastCGI/GT.M interface. I've looked
> over the
> alternatives (namely the M/* apps from M/Gateway) and while they look
> great,
> I've had an itch to implement something a bit closer to traditional
> CGI.
>
> Recently I hacked an interface together using call-ins. It works, but
> is quirky
> enough to render it unusable:
>
> 1. When I write using printf() before the call-in, I see the output as
> expected in the browser.
>
> 2. When I write using WRITE within the M routine, the output appears
> in
> the apache error log. The command WRITE $IO shows 0. On my plain CGI
> version it shows 1 (which makes sense given that its writing to
> stdout),
> so I think something may be amiss here.

[KSB] GT.M does play with $P if it thinks it is a terminal device, but
not if it is a file or socket. But the difference in $IO is
interesting. It should be 0.

> 3. Subsequent calls to printf() appear to send the string "nowhere."
> It
> doesn't appear in the browser or in the error log. (I'm thinking if I
> fix #2 this will follow.)

[KSB] You're probably right.

> The FastCGI library I'm using (the one available from the website)
> fiddles with std{in,out,err} to maintain compatibility with old CGI
> programs. This works splendidly as long as I stay in C, but GT.M
> appears to manipulate the devices differently (perhaps when setting up
> $P, I don't know). I feel like if I get this one last detail working,
> I'd have a neat little library.

[KSB] Many people have experience using GT.M with CGI, but not
FastCGI.

Regards
-- Bhaskar
ks dot bhaskar at fisglobal dot com <-- send e-mail here

Sean Woods

unread,

Nov 17, 2010, 6:24:32 PM11/17/10

to

Thank you. Rob, I'm interested more from the perspective of general
nerdiness than anything else. Also, I wanted to experiment with call-
ins and thought this might be an interesting little project - and I
did learn a lot!