No... You aren't going to lose me to PHP ... PHP is a "scripting" language, and it allows for "active" pages to a larger degree than SSI does -- and without the penalty (apparantly) if you don't count the bloated apache
But, rather than having Links generate .html or .shtml pages, I think a combination of .php3 pages, to cut the "build" time for the static pages (I know this is an oxymoron here, but ...) Rather than generate a huge site dynamically, which would require a lot of database processing, and penalty that could be done _once_ during a nightly or even weekly build session (or in the case of a truly large site... continuously) PHP would add to the static pages data that changes on each page load -- such as advertising, site statistics, news clips, etc.
I don't think the two are mutually exclusive. The more I read, and play with the servers, perl, PHP, etc the more I see no one solution can do it all.
In searching for a shopping cart, forum program, and advertising program, the current limitations don't allow for real integration. Most of what is out there _sucks_ (pardon, but that _is_ toned down).
As for Apache::ASP or Embperl, embperl I don't think is "there" yet. I'll check it again, but last time I looked, it was still pretty developmental and "bleeding edge" for production environments. As for "ASP" -- I don't want to use anything that reminds me of M$ <G>..... but I'll check it out, since I haven't really evaluated it yet.
What is needed, is a way to generate a site, with a combination of static and dynamic pages. If certain page data doesn't change very often, then _that_ could be stored in an SQL database, but generated ahead of time, while the parts of the page that change, can be requested on each access. This cuts the processing load -- especially of redundant non-changing requests.
I may be all wrong in this, but I'm looking at developing a very large site -- if not in the pure number of links, in the number of fields, tables and data relations that have to be handled.
At my current load, I could do pure dynamic, but as I follow the growing pains of sites like ebay -- the need for pre-generation of the "templates" (if you will) is more important, filling in only the data that really needs to be there.
If Links generates the php pages, (or other script pages) then it does most of the work as a "program" (perl is in that in-between realm - like BASIC) to generate the individual templates (each link would essentially be it's own custom template).
When that page is then requested, rather than using page.cgi to generate all the data, and figure everything out, the scripting language would just "fill in the blanks" left by the nph-build.cgi
Then, this would allow dynamic linking of advertising, shopping and other add-ins, such as context-sensitive or time-sensitve content without rebuilding the whole site.
It's all still experimental on my end -- but PHP has shown it's utility in the Admin program, and there are some nice PHP add-ins that would solve a lot of problems -- at least in the short term -- many people have in site development with pure perl.
[[Basically, I'm stressing, since I have major server/domain/etc upgrades in progress, and I'm trying to figure a way to integrate it all without it becoming an administrator nightmare]]
------------------
POSTCARDS.COM -- Everything Postcards on the Internet
www.postcards.com LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/ [This message has been edited by pugdog (edited February 16, 2000).]