[rescue] spam WPOISON

[Curtis H. Wilbar Jr.]

>From: "Jonathan C. Patschke" 
>
>On Mon, 8 Sep 2003, Curtis H. Wilbar Jr. wrote:
>
>> Given a running webserver with a memory resident language choice (Perl,
>> PHP, possibly others), I would use that technology because it is there, and
>> it is resident.  It may not be the fastest, but speed is not everything.
>> There is the overhead of file handles, process management, memory management,
>> etc.... the fastest solution is not always necessarily the best solution.
>
>Then, the problem becomes portability.  I don't run mod_perl.  I do run
>PHP.  Some sites don't run PHP.  I want my tool to be available to the
>greatest audience.  So, I can use a traditional perl CGI or a
>traditional C CGI.  C wins, hands down, in terms of not overloading the
>server.

So for you CGI and the common most supported language/environment on
the target platform(s) is what you would want to use.

All of this is dependant on:

1. Target Market
2. How far you want to go to please everyone in #1
3. How little you want to require (besides your product) of everyone in #1

A webserver is a requirement... not everyone runs one of those (but they
could have e-mail... this tool arguably benefits those with e-mail).  What
about those that don't run a webserver in their domain ?

All this plays a point in implementational choices... in this case:

1. which web server(s) to support
2. which modules/environments/languages/etc requirements will there be 
3. which hardware/os platform to support

>
>If C presents a portability problem on your server, you have other
>problems. :)

Like a pay for compiler for instance ?  Depends on your market... if
you are not making the binaries, requiring someone to shell out $500-$2000
just to be able to compile your program to use it will lock some people
out (even though you used 'C' to open it up to them).

Even if gcc is available for that platform, if it isn't bundled or
a current binary available, then your requiring them to get gcc, and
go through compiling it (assuming they can get a binary of an old gcc
or something to begin the compilation process gcc requires).

Pretty much everything can be a requirement (including hardware, os,
compilers, libraries, modules, webserver, etc).


>
>> Doing text processing in Perl or PHP is friendlier and more enjoyable.
>
>No doubt.

I hate doing some text processing jobs in C ... but depending on the
program/job/etc I do anyway because the whole or rest of the application/
system/etc merits it.

>
>> I don't potentially need to deal with memory management issues,
>
>Am I the only person on the planet that isn't bothered by this?
>Resource management is just part of programming to me, like syntax or
>logic.

I'm generally not bothered by it either... but it is a common gotcha in
complex programs (who knows how many memory leaks there are undiscovered
in OS/applications ... probably countless thousands some of which will
probably never be discovered).  It can add to the time to create the
application (by having to debug complex memory management issues), etc.

I'm not saying avoid languages that make you do your own memory management.
I even sometimes prefer that... but just because a language doesn't force
me to do my own memory management doesn't mean I will/wont consider it
as a possible language for something that needs to be written.

>
>> BTW, if you want this to be really efficient, code in native assembly and
>> even better... in assembly as a Apache module.  The ultimate in efficiency.
>
>But much less portable.

agreed... anywhere between best and furthest from best is where the ideal
solution/language is for any task.... finding it based on all the criterea
is the challange... there is no universal correct answer.

Curtis Wilbar
Hawk Mountain Networks

rescue at
        h
t       a
e       w
n       k
.niatnuom

My e-mail is protected against viruses and spam by MailGuardian
                  http://www.mailguardian.net
          Top notch protection at unbelievable prices