Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Web Programming by printf() 104

Posted by timothy from the bare-essentials dept.
An anonymous reader writes "Art & Logic has posted an article titled 'Why CGI is Evil'. CGI might be an obvious way to create a simple web application, but this article provides some excellent high-level reasons why CGI rarely makes long-term sense. A nice review especially for new web programmers."
This discussion has been archived. No new comments can be posted.

Web Programming by printf() More

Web Programming by printf()

Comments Filter:
  • First GOTO [acm.org] and now CGI [artlogic.com]. Why doesn't someone call C evil so we can call it a night

  • cgi underrated (Score:1, Insightful)

    by Anonymous Coward
    One of the author's complaints against cgi was the slowdown and overhead of having to fork a separate process. Let's look at that claim.
    There is a penalty to forking, but there is also a penalty to running interpreted code (java, php, perl, etc). Additionally, for scripting languages like perl and php, there is also cost of parsing and validating the code -- something that doesn't need to be done with compiled C code, and which takes a much longer time.
    Additionally, forked CGI runs in its own process space, and can't cause errors with the web server (IIS/apache).

    • Re:cgi underrated (Score:2, Interesting)

      by WoTG ( 610710 )
      True, there is a penalty to interpreted code, but a lot of this penalty can be mitigated (in PHP at least). The folks at Zend offer their PHP accelerator, and I use the ion cube [ioncube.com] (free as in beer) on my puny home server.

      Both of these compile the scripts, and parse, and validate _once_ (per reboot). For every subsequent call to the script, the server just runs the cached copy of the compiled code. So, you get all of the benefits of the scripted language, i.e. speed of coding, and fewer of the downsides.
    • Apache 1.* forks another process to handle web requests and it is not particularly slow. Apache 2.* uses threads. mod_perl runs under either version I believe. With mason, you aren't even writing cgis anymore either.

      As for IPC, most IPC should be done through a little piece of software called *GASP* a database. If you really need something other than that there are modules ( IPC::Sharable comes to mind ) that make IPC easy. Write a nice wrapper around your use of that and it is not hard - really.

      Purveyors of Application Servers are just marketroids that try to FUD middle managers into telling their programmers to scrap all their perfectly functional and extensible code so they can buy ( for mucho $$ ) a buzzword-compatible 'framework' that their programmers will have to learn. This framework will be closed source and won't do everything you want it to. You will find yourself wanting to change something that you can't.

      "But what's to change? Our framework has modules to speak tons of protocols and zillions of useful utilities." they say

      SO DOES CPAN! and you can look at/change the source of those! I seriously doubt there is a canned Application Server with a 'useful code' library that can compete with CPAN.

      But middle manager types make their careers by taking 'ideas' from salesmen and then taking credit for getting them implemented, so many will find themselves in charge of bigger budgets and get promotions for causing existing code to be reimplemented with an inferior product that locks their companies into spending more money. ( Look at how much money I can spend! Gee that's alot of responsibility. I need a raise or a promotion or something for pissing this much away! )

      • SO DOES CPAN! and you can look at/change the source of those! I seriously doubt there is a canned Application Server with a 'useful code' library that can compete with CPAN.
        The developer exchange and cold fusion library for cold fusion comes close, but that only include web based stuff so it looses out to CPAN because it contains alot of stuff that would is not likly to be used in web development.
  • Executive Summary: CGI is slow, and you can't really use MVC principles. The end.

  • CGI still has uses (Score:3, Insightful)

    by LordNimon ( 85072 ) on Monday February 17, 2003 @04:49PM (#5321652)
    What if your CGI programs need to get data from libraries that only have C and C++ interfaces? On the embedded system I'm working on, everything that talks to hardware is written in C or C++, and in many cases the only way to get the data my CGI programs need to is to call a C++ class library. No one would take me seriously if I proposed writing this stuff in PHP or Perl.
    • You could, for example, use JSP and write a taglib that calls the C interface using RMI. Or the equivalent for whatever your server is capable of running.

      Remember, the reason that most libraries give a C interface is that most other languages can talk to C. It may not be pretty and it may not be easy, but if you can access it in C, you can almost always access it in another language.

      • Wouldn't that require running Java on the server? And what about the C++ interfaces? Can I call those from Java?
        • If you're using JSP, then yes, you'll have to run Java on the server. However, JSP was just an example. If you write a plugin to PHP, you won't need to run Java.

          As for the C++ interfaces, I believe that you can interface C++ directly to Java, but I'm not positive. However, you can write some wrapper code to put a C interface in front of the C++ interface, then connect your script to the C interface. As I said, it may not be pretty, but it can be done.

          If you need to work in C and only C (for example, your embedded system doesn't have room for a PHP interpreter or for java), there may be systems that translate from a template into C code. This is how JSP works - it translates from a JSP template to a Java servlet to Java bytecode. It should be possible to write a similar system for C, but I don't know if it exists.

    • Without much hassle, you can use XS to allow your Perl scripts to interface with C/C++ libraries in a natural way. In fact, many Perl modules are written in C/C++ and wrapped with XS. This allows you to get the best of both worlds in some situations -- streamlined C code to offload intensive operations into separate libraries, then rapidly prototypable Perl front ends to those libraries (whether it be mod_perl for web apps, Perl/GTK for GUI, or any other type of front end you need).

      It's not always the perfect solution, but your post makes it seems as if you don't think there's any way to get C and Perl to talk. Few things are further from the truth. And this isn't just some nifty Perl thing -- many of the "scripting" languages (I can't speak for PHP) offer similar ways to accessing C/C++/etc. I'm just most familiar with Perl's way.
    • > What if your CGI programs need to get data from libraries that only have C and C++ interfaces?

      Write a little server in C or C++ that listens on a port (local connections only). Then have mod_<favorite langauge> connect to it for data. Should be faster than CGI, but without the hassle of trying to figure out which language to embed into some other.

    • What if your CGI programs need to get data from libraries that only have C and C++ interfaces?

      Python has really good interfacing with C/C++ code [python.org].

  • Misuse of an acronym? (Score:3, Interesting)

    by Masa ( 74401 ) on Monday February 17, 2003 @04:50PM (#5321654) Journal
    I thought that CGI stands for Common Gateway Interface and is a standard method of transferring information between a server and a client. The method doesn't say anything about the language used. The article gives an impression that CGI is equal to C programming. Isn't CGI a base for almost all WWW browser based client-server communication? What other methods are available? RMI? Bare TCP/UDP sockets? How .NET transfers data between the browser and the server? How Java Server Pages do it?

    As you can see, I'm not a web programmer and the article actually made things more unclear for me. Did I misunderstood something? Can someone clarify things up for me, please?

    • Re:Misuse of an acronym? (Score:5, Informative)

      by aridhol ( 112307 ) <ka_lac@hotmail.com> on Monday February 17, 2003 @05:00PM (#5321713) Homepage Journal
      No, CGI is between the server and its subprocesses. The connection between your browser and the server is HTTP, and the connection between the server and scripts is CGI.

      I think CGI also refers only to those programs that the server calls directly passing headers in a certain format. While the script may be written in any language, they tend to be written in a language that is primarily a programming language (Perl, C, Python, etc) rather than a content-oriented language (ASP, JSP, PHP, etc).

      JSP usually runs as a separate server that may be contacted by the web server, but is also capable of answering web requests by itself. ASP and PHP are run in the same process space as the web server, and thus can spare the overhead of spawning a new script interpreter for every request. All of these languages are content-oriented, meaning that the scripting code is embedded in the document, rather than having the document embedded in the code.

      Hopefully I haven't confused matters even more ;)

      • Re:Misuse of an acronym? (Score:5, Informative)

        by Sentry21 ( 8183 ) on Monday February 17, 2003 @05:12PM (#5321781) Journal
        I think CGI also refers only to those programs that the server calls directly passing headers in a certain format.

        CGI refers to the method of executing external programs, passing parameters to them as environment variables, and then getting the result back from standard output. CGI tends to be external binaries, and thus PHP can be essentially CGI if you use it in its CGI binary form (needlessly complex, and even worse of a performance hit, but it works).

        JSP usually runs as a separate server that may be contacted by the web server, but is also capable of answering web requests by itself.

        Most of the servers I've seen tend to glob everything together, so I'd be inclined to disagree with the 'usually' here. I've usually run it as the 'tomcat' process, which is its own thing.

        You neglected to mention servlets, which are a nice cross between CGI and markup languages like ASP/JSP/PHP. Servlets are small Java programs that are mapped to a directory on the website (like /administration/). They're compiled and placed into the classpath, and then the server executes them in the JVM when a request is made. The benefit is that the code is precompiled and the JVM is preloaded, so the execution time once loaded is almost as fast as a CGI applet would be once loaded, but the load time is less because it doesn't have to fork a separate process.

        That's my imput for the day. If Aridhol hasn't confused matters enough, this hopefully will.

        --Dan

        • Re:Misuse of an acronym? (Score:5, Insightful)

          by aridhol ( 112307 ) <ka_lac@hotmail.com> on Monday February 17, 2003 @05:18PM (#5321813) Homepage Journal
          Servlets are small Java programs that are mapped to a directory on the website (like /administration/). They're compiled and placed into the classpath, and then the server executes them in the JVM when a request is made.
          Yes, servlets exist, but I feel that they are closer to CGI than to template- or content-based languages. In order to create any output, you still have to use a print()-like function (haven't done much with Servlets, so I can't remember the actual method used here).

          However, a JSP is automatically preprocessed into a servlet before it's compiled into bytecode, so it actually is a halfway point ;)

          • Yeah, servlets are closer to CGI than preprocessed languages, but CGI is the topic of discussion.. :P

            JSP is automatically preprocessed into what could possibly be said to be a servlet, but the same basic thing happens to PHP pages, and, I expect, to ASP pages (active server page pages?), so aren't those pretty similar too?

            Man, this is making my head hurt.

            --Dan
            • Similar, except that the JSP spec actually mandates that the JSP be translated into an actual servlet (a Java class adhering to the Servlet API) to simplify debugging. There may be an intermediate form in PHP and ASP (I'd be surprised if there wasn't), but AFAIK JSP is the only one to have the intermediate form specified.
              • Similar, except that the JSP spec actually mandates that the JSP be translated into an actual servlet (a Java class adhering to the Servlet API) to simplify debugging.

                The idea that this simplifies debugging is a joke. Debugging of the appserver or JSP-to-Java translator, maybe, but its a pain in the ass for debugging the JSP itself.

                I personally have seen one too many message like "NullPointerException at __some.__absurdly.__long.__filename.java(65535)". Then you have to go find this intermediate form (which some appservers might've actually discarded by this point, unless you were smart enough to configure them otherwise). Once you find it, you usally see Java code that is only slightly more readable than an octal dump of the compiled class would've been.

                Then once you figure out what caused the bug and how to fix it, then you have to mentally translate your fix back into JSP from Java, because the JSP is what you have to edit to go make your fix.

                The only positive is that the whole experience is painful enough that it will encourage even the laziest person to learn a framework like Struts, so they can get as much of their code as possible out of the JSPs.

          • Servlets and .JSPs become the same thing behind the scenes, but they are conceptually two different things.

            (The following assumes that developers are using a reasonable architecture, rather than ad-hoc throwing together of technologies)

            To take an MVC view of this, servlets are primarily used for the controller portion of an application. As straight Java code written to a specific interface, they provide a natural linking point between .JSP view components and JavaBean model components. Typical use is one or a few controller servlets, which receive requests from .JSP forms and invoke logical operations in JavaBeans or Enterprise Java Beans. You want to avoid putting VERY much logic into the servlets, instead deferring processing to the business object layer.

            A framework like Struts enforces this by providing you with a pre-packaged controller servlet, which you extend with a combination of classes that are servlet-like and XML to bind 'em all together.
    • See my journal entry about this. I had an entire rant about this.

      http://slashdot.org/~sporty/journal/20356 [slashdot.org]
      • Unfortunately, your rant is wrong. CGI is not an interface between a server and a browser at all. That interface is called HTTP.

        CGI is an interface between a webserver and external subprocesses that has been in decline since faster alternatives started appearing in about 1995. While it is technically possible to write CGI programs in Java, PHP or Perl, it is not common. Servlets, PHP, mod_perl and other modern ways of generating dynamic content do not use the CGI interface, instead they have their own more efficient interfaces.

        • I'm sorry, but I believe you are mistaken. CGI's work over HTTP in terms of the get and post methods. In terms of their encoding and all.
          • You can beleive all you want, the HTTP protocol is what defines GET and POST methods, and URL encoding.

            CGI on the other hand defines how that information can be passed to external programs by the server (using environment variables and standard in), and how the external program passes information back to the server to be sent to the browser (via standard out).

            A full specification is available from NCSA [uiuc.edu]

    • Re:Misuse of an acronym? (Score:5, Informative)

      by cant_get_a_good_nick ( 172131 ) on Monday February 17, 2003 @07:23PM (#5322447)
      CGI is pretty much the oldest method of a web server interacting with outside code, and is kind of the only standard way. The server fork/exec's a process and has the CGI process' stdin, stdout, and stderr are pointing back to the server. The web server passes information either through environment variables (for a GET request) or additionally through the process' stdin (for POST and PUT requests).
      Advantages: very clean, the process goes away after the request, so resource leaks aren't a problem. Very simple interaction, if your programming language understands stdin, stdout, and environment variables (hard to find one that doesn't) you can do CGI with it (though some are better than others obviously).
      Disadvantages: fork/exec for every request. That has some overhead, sometimes more important is that the process can't use persistent state. Resources have to be acquired on every request. Anything with a great deal of overhead, say opening a database connection, has a HUGE impact on the server.

      FastCGI is a pseudo-standard in that it has multiple people implementing it, but it never got approved by, say, the IETF. It's a client server kind of thing, where the first instantiation starts the server up and initializes it. Subsequent requests get sent to the CGI server and get returned. The CGI server never goes away. The cool thing is that there are no startup costs, and you can keep something like a DB pool. Never really used it, so can't comment much.

      Some things just get embedded into the server, like Apache modules. You can write C code and it becomes part of the server itself.
      Advantages: wicked fast. Full access to anything in the server.
      Disadvantages: if your CGI has a problem, it can bring down your server. The API's can be pretty arcane. Also, it's a different API for each web server (NSAPI vs. ISAPI vs....) and even between variants (it's wildly different from Apache 1.3 and apache 2.0).

      mod_perl is kind of like above, it's a perl interpreter bound into Apache. Gives a perl interface to pretty much everything apache has to offer. Not only requests, but configurations.
      Advantages: perl is very flexible, can do a lot of things and use perl modules from CPAN, including templating systems and the such. You're also insulated a bit from stray pointers and such. mod_perl also precompiles all of the perl code, so you don't have the compiler overhead on every request.
      Disadvantages: mod_perl can be huge sometimes, and if you have several mod_perl instances running around, you can eat memory pretty quick.

      Everything else is kind of "do what you want". Tomcat itself has several protocols to talk to Apache; some are just old, some are supported on certain platforms only, yadda yadda.

      That said, the article did confuse a bunch of things, CGI, C, and content management systems. He was pushing an agenda, hopoing that people couldn't see through it.
      • I've been using C-based CGIs for years - once I started doing it and got used to coding everything in C, and developing my own libraries and what-not, it was very difficult to change.

        Seems to me the overhead's pretty low compared to the competition. People argue for things like JSP as more efficient and cleaner than CGI, but I've never seen a JSP web site that's not dog slow.

        When I started reading that opening a database connection had enormous overhead, I got worried that I was really doing something dumb. So I wrote a program to open and close a mySQL database 1000 times and it took a total of 2 seconds. That's 0.002 seconds per open/close combination.

        Then I stopped worrying and went back to work. I'd rather be right in practice and wrong in theory than vice versa.

        D

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Monday February 17, 2003 @04:57PM (#5321695)
    Comment removed based on user account deletion
    • When you consider that all (or most) web servers in the embedded systems market are currently using CGI, the author's article is quite brilliant. Remember, the embedded systems world is about 5 years behind the traditional "web development" world. The embedded guys are using many of the same technologies but for completely different purposes. For example, it looks like Art & Logic is also using XML-RPC and SOAP, but in a completely different context than most of us are used to.

  • This is a press release (Score:5, Insightful)

    by legLess ( 127550 ) on Monday February 17, 2003 @05:09PM (#5321766) Journal
    Notice how the author compares CGI unfavorably with something he calls DMF? Here it is [artlogic.com], and it looks like one of the flagship products of this company. Imagine that.

    He's setting up a straw man, then claiming that his own (proprietary, for-profit ... not that there's anything wrong with that) solution is better. When he says "CGI" he's talking about something that few people use for anything but toys. Slashdot (e.g.) uses the Perl CGI module, but runs it under mod_perl, thus obviating most of his arguments (CGI is slow, must be compiled at run-time, and has no access to the web server internals). Slashdot, again, uses a templating system, thus taking care of his second argument (programmers must copy-paste HTML into their code).

    Both these problems have been solved for over 5 years, yet he's trying to make it sound like his beautiful DMF is the first to even discover them. *Yawn* - another press release day on /.
    • Yeah.. But CGI is EVIL. at least without a decent templating system. And I'm not that big a fan of the source code in HTML model used by things like PHP. Where I work we use XML and XSLT to seperate content , machanics, and formatting. It's enough to make web progamming sexy. Not as sexy as low level bit twiddling but hey what is? Oh yeah.... low level bit twiddling with girls (either context works).
    • If you want to know how CGI can be made real fast, then lookee here: CGI-lib [geocities.com]

  • Bunk! (Score:5, Insightful)

    by HRbnjR ( 12398 ) <chris@hubick.com> on Monday February 17, 2003 @05:15PM (#5321802) Homepage
    This is bunk! Pure FUD!

    CGI is slower?? I write CGI in C++. Compiled C++ is fast. It's on par with interpreted Perl or PHP execution speed at the very least... more likely vastly faster. And this myth about process spawn time is starting to bother me. Linux can spawn processes VERY fast. Threads on Linux have traditionally been implemented as a special form of process anyhow. And even if this was a problem...the author mentions the solution, FastCGI - but seems to somehow ignore that it obliviates his whole point!

    What people really like to ignore when developing on Windows is COM, Apartment Threading, and the whole process model. When you call a COM object in an ASP page or whatever, you are crossing process boundaries - all arguments are martialled through COM by VALUE. All these ASP programmers that create a COM object to use, for example, MSXML have obviously never tried creating a LARGE DOM tree. Let me tell you, it does NOT scale. Compiling all my code into a single CGI allows me to keep everything in the same process space, and vastly improves performance when things get large.

    And who the hell debugs using printf? For one, I like CGI because it's easy to launch one directly from GDB! Ever tried attaching a debugger to a thread for your process inside a web server? HA! GDB lets me easily script the piping of a file to stdin of my CGI. If you are still using printf, you have more problems in learning about programming than will be solved by not using CGI.

    Now, if your application is heavily template based, then yes, PHP definitely makes more sense than CGI!!! The other has a point in that you shouldn't be embedding HTML in your C code. Which brings me to my last beef...

    Their product is about using pre written features rather than writing them yourself as you need to with CGI? Uh, DUH!! There are like umpteen billion CGI LIBRARIES out there!!! I happen to like GNU CGICC. It does everything, form uploading (mime and file uploads too), cookie handling, templating, etc - and it works with FastCGI too! Write it yourself??? As if! And I have no problem linking in libraries for database access, and everything else under the sun (Boost, etc) into my CGI, just like I would link them into any other program. Who the hell writes software without using any libraries?

    This article is basically a bunch of FUD just to sell their product. You can safely ignore the whole thing!

    • Re:Bunk! (Score:2, Interesting)

      by Slorf ( 576160 )
      Agreed, totally bunk. If you're actually doing what they suggest, cutting and pasting blocks of someone else's html into your code and/or mixing static pages and code sections, then yeah, you might be inefficient. However, most intelligent CGI programmers will write functions/methods to output the majority of the content, and then supply the data to those functions. If you write your presentation code in this manner, you can put it in a library and call that function again and again from different programs to get a consistent look and feel.

      Of course, as the previous poster implies, there are a lot of pre-written libraries out there as well, and not only in C but in Perl, Python, Ruby, and every other langauge that someone has used for building CGI programs. Templating is fine for those who really need to separate the presentation from the business logic, but if you're doing both parts it is far easier to maintain one pure CGI code base that handles the presentation through well thought out functions.

    • Hey man ... (Score:5, Funny)

      by torpor ( 458 ) <ibisumNO@SPAMgmail.com> on Monday February 17, 2003 @07:41PM (#5322535) Homepage Journal
      ... back off printf();

      I'm with you on everything else though bro'!

    • Re:Bunk! (Score:1)

      by Anonymous Coward
      "And who the hell debugs using printf? For one, I like CGI because it's easy to launch one directly from GDB! Ever tried attaching a debugger to a thread for your process inside a web server? HA! GDB lets me easily script the piping of a file to stdin of my CGI. If you are still using printf, you have more problems in learning about programming than will be solved by not using CGI."

      Excuse me while I laugh.

      Smart developers use any tool availible to them. Printf is highly useful for debugging. If you don't realize how it can be useful, then perhaps you should pick up a copy of an introductory programming text.

      • Didn't you read it? He writes his CGI in C++, so of course he doesn't debug using printf(). Clearly using iostreams is a far superior solution for his application.

    • I doubt it's much faster than mod_perl. Mod_perl can be set to compile once at server startup, then run many times. In addition, it has no fork time at all, another benefit.

      PHP has to compile every time, so it's slightly slower, but you can do neat things like use persistent MySQL across all sorts of scripts.

      Perhaps some of this can be fixed with FastCGI, although Perl and PHP are (IMHO) much easier to learn and write. In addition, I'll bet there's a large enough IPC overhead to make this FastCGI with C/C++ less attractive than mod_perl or PHP.

    • Debugging with printfs (Score:4, Insightful)

      by p3d0 ( 42270 ) on Tuesday February 18, 2003 @08:38AM (#5325191)
      Actually, sometimes debugging with printfs is much better than gdb. Two situations occur to me:
      • The problem is nondeterministic. If the failure occurs only once in 100 runs, you probably won't see it when you run it in gdb, especially if it's timing-dependent (in which case gdb may stop it from occurring at all). However, with a proper debug trace, you can just grab the log file when the crash does occur, and do a lot of diagnosis from that (plus possibly the core file if you get one of those).
      • The program state and state transitions are too complex. For instance, try to debug a compiler without a good debug trace facility. It's just not very practical to walk complex IR data structures manually after various optimizations have been performed.
      • You forget on situation: when the problem does not occur (goes away) under gdb. This is more frequent than many people realize.
      • I prefer debugging by syslog(3)

        Most of my web cgi code has a fair amount of syslog calls in it for various conditions, all with appropriate severities.

        On live code, I call
        setlogmask(LOG_MASK(LOG_WARNING) | LOG_MASK(LOG_ERR) | ... | LOG_MASK(LOG_EMERG));
        so that only error conditions (like being unable to contact the backend database) get logged. I then have all the live servers forward their logs to a central server, which emails me (via a tiny script I cooked up) each syslog message with a severity of LOG_WARNING or above it gets. This means I get instant notification of web errors in my inbox, which is really handy.

        But for debugging purposes, I can just comment out the initial call to setlogmask(3) on the test server, and run the program in one window while having
        tail -f /var/log/messages | less
        running in another. As soon as the error pops up, I can check the debug syslog messages in the messages file. To remove them *all*, I just put the one setlogmask() call back.

        Really handy.
        • Not bad, until you try to port your software to Windows. :-)
          • That's what cygwin is for. Alternatively, just write your own setlogmask() and syslog() - they're not too complex - a few #defines, setlogmask() sets bits in a static variable, and syslog() writes to the Windows application event log if the logmask is correct. 100 lines of code, tops.

  • It seems like the author thinks the majority of CGI apps are written in C.

    ...when the complexity of the response grows, the C programmer is forced to emit complex blocks of HTML from C code... Requiring that the interface be generated by C code also removes the possibility of replacing or updating the web interface in the field without replacing the entire binary image of the server
    On cgi.resourceindex.com, there are 2933 Perl scripts and 165 C and C++ scripts combined.

    This would seem to disprove his point that the "binary image" on the server must be replaced every time one wants to edit the html...
    • I have not used a print statements to output html directly in years of CGI programming. The use of templates completely obviates the need to use print or printing "here" documents. The article is pure gibberish.

      In fact html in the code is considered sophomoric where I work and is shunned.

      Too bad slashdot does not have a mechanism to rate the article it reviews.
      • Excuse my ignorance, but how do you get the HTML code back to the user?
        • The cgi application processes a template which consists of replaceable parameters, this template is then sent to standard out - no html exists in the code and the template is viewable and editable using the browser/html editor of your choice. The process is sort of like this

          cgi_app.pl --|
          -----> std_out
          Template.html --|

          There are a variety of template processors out there (at least for Perl and Python far as I know), the one I use and have grown to love is TemplateRex [perlworks.com]

          • Oh, I see.

            I guess I use a mixture.

            Most of my HTML is a table with some stuff on the top and some stoff on the left. And I have the main body of my page in the bottom right.

            Also, I want to be able to do a lot of stuff in the head, like change the title, or create meta information.

            Therefore, I create my own stuff each time. I can also change the content-type if I need to. Then I create a before template and after template. The before template is the HTML that sits before my main body and the after template sits after it. I could look for a content or something, but by splitting the page up, I avoid having to search for stuff in the page, which saves some time.

            But perl still ends up reading each line of the template in and printing each line of the template out (some lines modified), right?
  • The author argues:
    The first difficulty encountered when programming CGI applications is the practice of "web programming by printf."
    and claims either the server-side programmer needs expertise in HTML, or blocks of HTML produced by a designed need to be copy and pasted into the C code.

    Has the author never had never heard of templating systems? The issue here lies with the architecture and design of the application itself, and not the use of CGI. You surely don't write your Java servlets using out.println(), do you?

  • int main(int argc, char ** argv)
    {
    printf("I disagree.\n");
    printf("CGI is great - ");
    printf("I don't see why anyone doesn't like");
    printf("writing web pages like this!\n");
    printf("CGI all the way!\n\n");
    return 0;
    }
  • I've written jsp, asp, php, cold fusion, perl, vb, and even the slightly less used shtml and of all of them, I much prefer php.

    I love perl for many things, but in terms of web page development, I can't stand it - I'd much rather have it running in the background updating files or databases and then have a frontend script like one of the **Ps come in and get the data and make it all purdy.

    JSP is retarded slow until the first time it has been loaded - which is all fine on a live system that precompiles at bootup (that always is blazing fast... right) - but for development, it could be a major pain in the ass - esp if you had anything remotely complicated in there.
    It is excellent to write in and I like that part, I just don't feel that the performance and ease of use are high enough over the others to merit me using it on any of the most recent projects that I've been doing.

    ASP is nice and relatively fast. It *can* run on a *nix system, but really, who are we kidding - it should be under IIS. I have very few complaints about it, but again, if given the choice - I'd rather use PHP.

    PHP is free, fast as hell, and has the best documentation - their site is fast, easy to use, and there is a discussion on the site at the end of each function description that allows you to post up different ways to use the code.
    It is enough like perl that I can flip flop between the two and not get too loopy trying to remember syntax, and yet it allows the easy tag manipulation that the server side scripting languages **Ps are good for.
    Did I mention it was free and retard fast?

    hot damn.
  • I think there are many times when PHP's print/echo and ASP's Response.Write need to be used. In every project. Functions generate output, and Response.Write sends it to the output stream.

    However I was shocked to use ASP.NET and found that unless ASP compat mode was turned on. to output something to the web page I had to create a label, set the label's text, then add it to the body/form control. Talk about the long way of doing something. It isn't any more flexible. It is much harder to change.

    IO, IO, It's off to work I go, 1 bit in and 1 bit out... IO IO IO IO
  • I frequently run my cgi's from a shell, to debug. first set some env vars (I use the uncgi() routine so vars are coming to me as WWW_foo). then 'dot-slash' the cgi and send the output to /home/httpd/html/test.html or whatever. easy and clean to run and debug.

    plus, cgi's JUST PLAIN WORK. nothing nonstandard, nothing platform-assuming, no browser extensions required, no heavy overhead. they Just Plain Work.

    oh, and they're frequently such 'least common denominator', so they're usually 'lynx-able'. try that with java or jscript code...
  • Scroll down a bit and you'll find a link to another article the guy wrote, about the "the benefits of using XML-RPC and SOAP" (emphasis mine). For god's sake, even if the CGI article wasn't a promotion for his company, anyone who thinks that XML-RPC and SOAP has any kind of benefits really can't be taken too seriously.
  • Seriously, this is some kind of timewarp or something. CGI? People still use that? Holy heck.
  • This is not a news article. It is a corporate advertisement for Art and Logic's Device Management Framework. It basicly says: Don't use CGI, use our product instead.

    Also there are a bunch of inaccuracies in the article. For one, there is no reason the HTML would need to be included in the C code (if you even use C with CGI. I rarely see it). Rather you would just put it in template files that the C code reads in. HTML layout changes would not need to be reflected in the C code.

    Thank God for moderators.
  • Its a bit like saying a 747 pilot might have to learn to drive a car to get to and from the airport. The skills to do the latter are virtually inconsequential compared to the skills required by the former so the point is trivial and irrelevant.

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close