Agreed,

I'm hooked on PHP. I'm currently investigating the best way for more direct
Image access then calling CGI's through PHP. It is very powerful & runs
completely on the e3000 so stability is not an issue. The documentation
from php.net is incredible, you do not need to buy anything to get into
php. Because PHP actually runs as a module under Apache, there is no start
time overhead to call it either (same idea as mod_jserv & mod_perl).

-Pete
At 08:42 AM 9/13/00 -0700, Shawn Gordon wrote:
>Let me take a moment to cloud the issue even further.  PHP totally rocks,
>and Bixby ported it to the 3000 one sunny saturday afternoon about 6 or so
>months ago.  It works with apache, runs almost everywhere and has great
>database connectivity built into it.  While there isn't a plug in for
>Image, it probably wouldn't be a big deal for someone to
>write.  http://www.php.net/
>
>that said, I'm becoming a huge fan of Python these days, and my company is
>even working on some IDE's for visual Python development
>(multi-platform).  While PHP is more tag based like Cold Fusion, Python
>would be a full server side scripting language.
>
>At 08:30 AM 9/13/2000, Michael Gueterman wrote:
> >   I'm not sure what you're meaning by "straight man" here,
> >but I'm simply saying that to state one language is "better"
> >then another solely by comparing the amount of time it
> >would take an average coder in either language to accomplish
> >the same task doesn't give an accurate measure of the worth
> >of the language as a whole (ok, talk about a 'run-on' sentence :).
> >I don't consider myself qualified to speak about the pro's
> >and con's of JSP (yet ;), but I can do so for Cold Fusion.  So:
> >
> >Pro's:
> >.  Simple.  CF is a "tag" based language that is very similar in
> >    appearance to HTML.  People that know HTML can quickly pick it up
> >    and become proficient in a short amount of time.
> >.  Powerful.  The CF tags and functions that make up the language
> >    allow for a wide variety of applications to be developed.
> >.  Extensible.  If the base language doesn't offer what you need,
> >    you can use COM/DCOM objects that may already be available
> >    elsewhere, or write your own in C++ or Java.  These are called
> >    'CF Custom Tags' and allow CF to take advantage of the functionality
> >    that may have been developed for other application server products
> >    (such as ASP).  This is how we use CF to perform the gateway
> >    functions between the 'comp.sys.hp.mpe' newsgroup and the HP3000-L
> >    listserv.  CF has the ability built-in to handle SMTP/POP3 email,
> >    but not for NNTP.  We purchased a small .dll that handled the
> >    reading/posting/etc functions for NNTP, and incorporated it into
> >    the CF template which does the bi-directional transfers.  By
> >    doing this, we went from writing the technical specs, writing
> >    code, to implementation in two days.  The bulk of that time was
> >    actually spent in the spec and QA stages.
> >.  Scalable.  If you need more power than a single box can offer,
> >    you can use the Enterprise version which includes the ClusterCats
> >    technology to add additional servers into a cluster for horizontal
> >    growth.  This allows you to build very large/redundant environments
> >    if necessary.
> >
> >Cons:
> >.  CF does not natively run on the e3000.
> >.  CF can not (easily) interface with an existing host-based
> >    application.  In other words, the existing business logic
> >    that may be present in the host-based application would need
> >    to be replicated into the CF code.  For "new" applications,
> >    this is not an issue, but if your going to take an existing
> >    host-based application to the web (existing rules/logic and
> >    all), then this may be a problem.
> >
> >   I've personally chosen CF as my "web application" language of choice,
> >but there may be times when I would choose something else (for example
> >if the customer already has experience with another technology and it
> >can perform the functions they require, there would have to be a very
> >strong reason to move that particular application to CF instead of
> >what they already have).
> >
> >So, I can't give you a single comparison that you can use to make
> >a decision as to which technology is best for a given purpose.
> >CF is but one of many and happens to be what I prefer.  Hopefully
> >this response is a little clearer for you than my previous one.  If
> >not, then let's take this discussion off-line and I can give you
> >more in-depth information about CF (which wouldn't really be
> >appropriate for the list).
> >
> >Regards,
> >Michael L Gueterman
> >Easy Does It Technologies
> >Allaire Alliance Partner
> >http://www.editcorp.com
> >voice: (888) 858-EDIT -or- (573) 368-5478
> >fax:   (573) 368-5479
> >
> >
> >-----Original Message-----
> >From: Cortlandt Wilson <[log in to unmask]>
> >To: [log in to unmask]
> >Date: Tue, 12 Sep 2000 13:06:12 -0600
> >Subject: Re: [HP3000-L] Apache vs. Cold Fusion  (was HPWorld 2000 On
> >Sunday)
> >
> > > "Michael Gueterman"  wrote
> > > > I think trying to compare development times between JSP/CF/ASP/etc
> > > > is silly and not really useful to anyone honestly trying to
> > > > decide what the appropriate technology is for a particular
> > > > application.
> > > (CF = Cold Fusion, JSP = Java Server Pages, ASP = Microsoft's web
> > > server)
> > >
> > > Huh?
> > >
> > > So you want me to be the straight man?    OK, what is THE "really
> > > useful" comparison
> > >
> > > - Cortlandt
> > >
>
>
>
>Regards,
>
>Shawn Gordon
>President
>theKompany.com
>www.thekompany.com
>949-713-3276