- From: Russell Holt <holtrf@destinyusa.com>
- Date: Fri, 17 Nov 1995 16:11:14 -0500
- To: Daniel DuBois <ddubois@rafiki.spyglass.com>, shuda@raja.destinyusa.com
- Cc: www-talk@w3.org
>>Yes, there are certainly CGI implementations in use right now which don't use >>stdio streams - for example, CGI scripts using Visual Basic (which has no >>concept of stdin/stdout), or scripts implemented as DLLs. DLLs don't use [..] > > I don't think the any CGI spec should be burdened with the > complications of WinCGI. WinCGI is a being into it's own, and has in > many cases, drastically different behavior. The Macintosh doesn't use stdio/stdout either. The server communicates with CGI programs via event structures. It also happens to be a popular Web server platform. The concept of stdin/stdout is showing its age, and doesn't translate well at all to integrated GUI environments. In fact, let's be brutally honest. CGI itself is one big ugly hack piggybacking on HTTP, especially the QUERY_STRING beast. Spaces to plus? Escaped chars? Hello? Those are implementation-specific hacks if I've ever seen any. We shouldn't be burdened with the complications of Un*x. It has its own idiosyncratic and drastically different behavior. > Let's keep this CGI spec useful, if we try to generalize to the > point you advocate, it will likely lose a great deal of utility > and precision. Maybe so... after all, it works now even though it's ugly. Trouble is, all software systems are intermediate steps and temporary solutions. -Russell
Received on Friday, 17 November 1995 16:11:09 UTC