- From: Mike Meyer <mwm@contessa.phone.net>
- Date: Fri, 17 Nov 95 13:34:05 PST
- To: www-talk@w3.org
> 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. Well, some integrated GUI environments, anyway. Works fine on others. Now, I know Perl CGI programs can be ported to the Mac. Does this require changing all the I/O operations to use something else? If so, I would argue that calling this a "CGI" environment is innacurate. If not, then apparently there is some way of turning the event streams into what appear to be I/O streams that can be used by a CGI implementation. > 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. While this makes sense, it makes even more sense to avoid burdening an application that doesn't need and shouldn't have a GUI with the complications of a GUI environment. Given that, can you come up with a specification that makes sense in both environments and allows programs to be ported between them? If not, then possibly CGI should be targetted at environments that support a CLI. GUI-only systems will need something different. Platforms that have both a GUI and a CLI can then implement both and take advantage of applications written for either one. <mike
Received on Friday, 17 November 1995 16:40:42 UTC