W3C home > Mailing lists > Public > www-talk@w3.org > November to December 1995

Re: CGI???

From: Mike Meyer <mwm@contessa.phone.net>
Date: Fri, 17 Nov 95 13:34:05 PST
Message-Id: <19951117.7B2CB10.C017@contessa.phone.net>
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

> 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.

Received on Friday, 17 November 1995 16:40:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:58 UTC