HTML Code for counter

I would stay away from CGI because the way in which it handles threads to the CGI program. My recommendation is to use a scripting language such as VBScript.

-Don

The way in which is handles threads....

OK -

(a) For something as simple as this - that isn't really relevent. A touch of file locking will deal with it (or you can use a database which is even easier)
(b) You can't replace CGI with VBScript any more then you can replace a road with a car. CGI is just a way for the webserver to talk to a script, you can use any scripting language you like
(c) The most popular webserver (Apache 1.x) doesn't even do threading
(d) Perl doesn't have to run as CGI

I agree with your comments on Apache and you can write Perl which is exactly what I suggested, "My recommendation is to use a scripting language". To that end, did the Usr say it was Apache? No, I do not believe so. That being said, I am not trying to start a "pissing war", I am simply trying to educate the Usr.

>>You can't replace CGI with VBScript any more then you can replace a road with a car. CGI is just a way for the webserver to talk to a script, you can use any scripting language you like<<
Explain please??? VBScript is nothing like CGI in the way in which it operates. CGI is a poor construction of engineers throwing stuff together and others using it as a way to perform a function; hence, why other languages were created to thwart those problems.

-Don

Apache (or another server) uses CGI to execute a program and returns the output of that program to the client (possibly adding a few extra http headers on the way).

This program could be written in Perl, VBScript, C, LISP, Python, Ruby, Postscript, or just about any other programming language.

CGI is not a language, its a protocol, and aside from its performance issues, a very good one (becuase its very flexible).

Anyway - Rick:

You have 2 choices - either script it yourself, or use somebody else's (the 3rd party Dorward mentioned).

The third party deals normally come with the "crap" you mention, as they want something back for their effort, so you probably want to script it yourself.

You need to find out if your server supports a Server Side Scripting language, eg ASP, PHP or Perl.  Once you know what you can use, go and Google, for example:

simple counter asp

and you'll get loads of short scripts the do it for you, that either store the info in a database or in a text file.

It's nice and easy, but as Dorward said, it can't be done in just html.  I wouldn't worry too much about the CGI debate - what you're doing is very low level as far as performance is concerned, so it'll make very little difference - just pick the one that you are most comfortable with.

Finally, I'd advise against using Counters - ugly things!  The only people who care about them are the people who design the site, and you can usually get that kind of info off the guys who host your website, but that's just an opinion.

> You have 2 choices - either script it yourself, or use somebody else's (the 3rd party Dorward mentioned).

No, both the options I suggested were using somebody elses, there are so many out there that coding from scratch is a waste of time (except possibly as a learning exercise). The 3rd party is who executes it for you if you can't run scripts on your own server.

>>Apache (or another server) uses CGI to execute a program and returns the output of that program to the client (possibly adding a few extra http headers on the way).

This program could be written in Perl, VBScript, C, LISP, Python, Ruby, Postscript, or just about any other programming language.<<

Yes, I am with you and I agree.

>>CGI is not a language, its a protocol, and aside from its performance issues<<

It is these "performance issues" that you speak of that I warn the Usr. Performance from a protocal that only handles one request at a time, is more times than not, the problem with bottlenecks. Hence, the reason for my original comment, "I would stay away from CGI because the way in which it handles threads to the CGI"

This is a good discussion! :)

I take it you are not a MS fan, huh?

-Don

CGI doesn't handle only one request at a time, the server spawns a new process for each request. The performance issues are down to it taking time to spawn the new process then something which is stored in memory (like mod_perl), but not due to any threading.

Sorry Dorward - I think you misunderstood me as I worded it badly.

I would re-explain, but I think you've done that quite nicely.  No points for me in this Q, incidentally.

Dorward,

With all due respect, we must get back on tangent for the Usr. I believe that we have a disconnect, but that is neither here nor there. Although I do enjoy it!

rick81,

Look into Webtrends by NetIQ. This may have all of the data you want without any coding, except adding JavaScript to the pages you want to track. It is an excellent program, but it does cost money.

There are many of these types of service providers out there and they may meet your needs, too. pepsichris and Dorward make excellent points that should be considered, as well.

Regards,

Don

Dorward,

Here is an excerpt explaining more elegantly what I was purporting: "When a server receives a request that accesses a CGI program, it must create a new process to run the CGI program and then pass to it, via environment variables and standard input, every bit of information that might be necessary to generate a response. Creating a process for every such request requires time and significant server resources, which limits the number of requests a server can handle concurrently. Figure 1-1 shows the CGI life cycle. "

This may be found at this URL should you doubt its authenticity: http://pub.spccatv.com.cn/~rison/servlet/ch01_01.htm

By the way this is O'Reilly and I think that it is safe for me to assume that you trust them if you don't trust me.

-Don

Which is what I said... (and isn't hugely significant, especially if the server has a fair bit of memory and a fast CPU).

Dorward,

Okay. I guess that what I was saying is what you were saying and what you were saying I was saying. Most servers are not fast and do not have a lot of memory and do not have fast CPUs because they were purchased before April of '00 (the Internet Crash-if you will). Therefore, my comment is significant.

-Don

That is something of a sweeping statement, and doesn't take into account the load on the server.

It is but if we accept your previous comment than we must make the assumption that your comment was "a sweeping statement", as well.

Out of curiouosity and with all DUE RESPECT, are you a web developer? Do you develop on the freeware side, such as PHP, Apache, etc., etc.?

To put it in perspective, I am a MS person. I do use Apache and other freeware/shareware type tools, but for the most part I try to stay on with MS. I do not have a BS in Comp. Science, but rather Finance with 6 years experience in computer-related experience with db, Internet, network, yada, yada, yada. To that end, I am sure that you are more knowledgable in this discussion that we are having than I. I enjoy this because I am learning, too!

Thank you,

Don

:)

I like your comment, "web authors practised standards compliant, accessible webdesign" in your profile. I think this is very applicable in the business environment, as well.

-Don

I think that as the discussion is rapidly heading towards an exchange of "my qualification if bigger then yours", there isn't much point in continuing it.

Dorward, that is not the point. Hold on their Cowboy. I was actually say'n that you are probably more qualified than I am. Damn. You engineers, as you call yourselves, simply cannot take a compliment. Do I know my stuff, yes. Am I good at what I do, yes. Does my salary at the age of 25 show that, yes. Does that mean that I good, no. I was actually saying that you are probably more accurate in what you are saying than I am. Therefore, learn to take a compliment or you will continue to be an engineer into retirement...haven't you learned this yet, or are still a Type B personality?

I WAS BEING COMPLIMENTARY AND BEING SUBMISSIVE. Have you forgotten what, "with all due respect" means?

-Don

> Have you forgotten what, "with all due respect" means?

"With no respect whatsoever" usually :)

I don't want to start listing qualifications, and I still don't see that any further relevent information can come out this, so there isn't much point in carrying on.

To each their own. I was simply trying to carry on a reasonable discussion. My apologies if I offended; that was certainly not my intention.

Respectively,

Don