asp, php or java, .net or what?

J

Joel Shepherd

Kim André Akerø said:
CGI = Common Gateway Interface

The computer language used is more or less any computer language you
can execute files or scripts with.

Right. So what sense does it make to say that "CGI is outdated", but
[insert computer language here] still has a chance? (I realize that
_you_ didn't say that.)

It's like comparing toothbrushes to meat. Sure, they're both things you
can stuff in your mouth, but the similarities pretty much end there.
 
N

Neredbojias

With neither quill nor qualm, =?iso-8859-1?Q?Kim_Andr=E9_Aker=F8?=
quothed:
CGI = Common Gateway Interface

The computer language used is more or less any computer language you
can execute files or scripts with. The most common language used is
probably Perl, but per definition, this is really up to the developer
of the CGI solution.

I use NIT because it has a higher rating.

(You know: Nit - 1, Perl - 2.)
 
A

Andy Dingley

Right. So what sense does it make to say that "CGI is outdated", but
[insert computer language here] still has a chance?

Because it is outdated

I see your point about the odd conjunction of disconnected statements,
but look at the OP. The question is "Is PHP obsolete" and I can't think
of a single web programming _language_ that is of itself obsolete. There
_could_ be such a thing, but I've not yet heard of PascalScript or
mod_eiffel.

CGI is a major component of some web scripting platforms. Perl was
regularly written for it, and most CGI coding probably used it. Now
CGI/Perl certainly is obsolete (use mod_perl instead). Now if your
choice of scripting platform depends on CGI, then that's itself a reason
for the platform to be regarded as obsolete - even if it's "CGI Java" or
some such.
 
T

Toby Inkster

Joel said:
Right. So what sense does it make to say that "CGI is outdated", but
[insert computer language here] still has a chance? (I realize that
_you_ didn't say that.)

CGI is a rather outdated mechanism for server-side programming. It's
inefficient. It spawns a whole new process for each page request.

mod_php on the other hand is run in-process by the web server. There are
similar modules for Perl and some other programming languages. This allows
richer communication between the script and web server, and is more
efficient.

In the face of such modules, CGI is outdated.
 
A

Alan J. Flavell

CGI is a rather outdated mechanism for server-side programming.

CGI specifies an application programming interface between a web
server and a server-side process. RFC3875 is an informational RFC with
a detailed specification of the software interface.

The server-side process can be programmed in any language which is capable
of supporting the interface specification. There's a wide range of
choices (I'm told that there exist CGI processes programmed in COBOL,
though I've never seen one myself).

The "mechanism" is decided by the server implementer.
It's inefficient. It spawns a whole new process for each page request.

It's often implemented in that way, but where does the specification
require that?
mod_php on the other hand is run in-process by the web server.

Comparing chalk with cheese. PHP is a lot more than just a programming
interface specification, and a lot less than a complete implementation
which can support server-side code in any programming language.
In the face of such modules, CGI is outdated.

CGI is very portable, on the other hand. This can be an overwhelming
reason for choosing it, when other considerations aren't dominant. Beware
premature optimisation.
 
M

Morgan

Go with Java, its got loads of support, it isn't microsoft, there is
lots of vacant jobs for a decent or even a crap java developer in
ireland. Also its unlikely imo to go the way of the dodo, it will be
used for a long time into the future.
However I seriously fail to believe that PHP is on the way out, its too
useful as of yet imo. Lots of jobs for PHP developers in ireland too.
 
T

Toby Inkster

Alan said:
CGI specifies an application programming interface between a web
server and a server-side process.
The server-side process can be programmed in any language which is
capable of supporting the interface specification.

I never claimed that the process couldn't be programmed in any language.

I was saying that the whole concept of the server dumping a bunch of data
into environment variable, spawning a new application (which may be
/usr/bin/perl or /usr/bin/sh or some other binary somewhere else on the
system), waiting for it to complete and then passing back the output is
inefficient. There are better ways of doing things.
There's a wide range of choices (I'm told that there exist CGI
processes programmed in COBOL, though I've never seen one myself).

Indeed. One of the first CGI programmes I wrote was in BASIC (classic, not
Visual).

All you really need is the ability to read environment variables and print
to STDOUT. Reading from STDIN is also handy if you want to accept POST
data.
It's often implemented in that way, but where does the specification
require that?

From your own reference (RFC 3875):

The server acts as an application gateway. It receives the request
from the client, selects a CGI script to handle the request, converts
the client request to a CGI request, *executes the script* and converts
the CGI response into a response for the client.

(my emphasis). The RFC specifies that the server should run an external
application (which it regretably refers to as a "script" even though this
application may be a compiled binary).
Comparing chalk with cheese. PHP is a lot more than just a programming
interface specification, and a lot less than a complete implementation
which can support server-side code in any programming language.

True -- mod_php is, but the concept of having modules at all -- of
building the script interpreter (and in some cases the script logic
itself) right into the web server is a valuable one.

Example: if a web server accepts a large amount of POST data, under CGI it
must spawn another application (spawning a new process is generally an
CPU-expensive process in most operating systems) and feed all this
information to the other application via its STDIN. If the data
interpreter is *part* of the web server instead of an external
application, the server just does a function call (less expensive
operation) and passes the POST data by reference (uses less memory,
takes less time) rather than by value.
CGI is very portable, on the other hand. This can be an overwhelming
reason for choosing it, when other considerations aren't dominant.

I'll give you that. Backwards-compatible too.

But if one wrote an application for processing data in, say, C, and wrote
it with care, it could just be a matter of changing a few line in the code
before compilation time to choose to compile an Apache module or a
standalone binary that interfaces to Apache with CGI.
 
N

Neredbojias

With neither quill nor qualm, Morgan quothed:
Go with Java, its got loads of support, it isn't microsoft, there is
lots of vacant jobs for a decent or even a crap java developer in
ireland. Also its unlikely imo to go the way of the dodo, it will be
used for a long time into the future.

What happened, did all the original Irish Java developers go the way of
the dodo, too? I guess that's understandable.
However I seriously fail to believe that PHP is on the way out, its too
useful as of yet imo. Lots of jobs for PHP developers in ireland too.

One time I wanted to get a job in Ireland but I didn't have a green
card.
 
A

Alan J. Flavell

Alan J. Flavell wrote:

From your own reference (RFC 3875):

The server acts as an application gateway. It receives the request
from the client, selects a CGI script to handle the request, converts
the client request to a CGI request, *executes the script* and converts
the CGI response into a response for the client.

(my emphasis). The RFC specifies that the server should run an external
application

Yes, but that doesn't mandate running it by a particular mechanism, i.e
your particular operating system's mechanism for spawning a new process.
Depending on OS, there may be more-efficient (though less-portable and
potentionally more-troublesome) ways of doing it more efficiently, that
get used in practice to speed things up, without changing the fact that
the API is still the defined CGI. Sure, as you say, there are other
approaches, too.
(which it regretably refers to as a "script" even though this
application may be a compiled binary).

It's a commonly-used terminology in this context, unfortunately, and even
finds itself used in the actual API, e.g the meta-variable SCRIPT_NAME.
I too favour the precise use of language, which this is not; but at least
the RFC makes a half-hearted attempt to define its usage of the term
"script" in its terminology section, i.e section 1.4. I'm afraid railing
against this usage now is too late, and wasted effort.

all the best
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top