Date: Fri, 17 Jan 1997 14:45:46 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Ade Barkah <mbarkah@hemi.com> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, freebsd-www@freebsd.org Subject: Re: Test CGI interface... (was: Re: cvs commit: www/data comm...) Message-ID: <Pine.BSI.3.95.970117141501.22331H-100000@fallout.campusview.indiana.edu> In-Reply-To: <199701171321.GAA16031@hemi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 17 Jan 1997, Ade Barkah wrote: > 1) Set up a database locally (Postgres 95 v6.00 beta), and moved > the gallery entries into the database. I've thought about having > them in a simple hash, but I think a full database will be useful > (for instance, the commercial entries can just be added as another > table.) Another plus is the possiblity of a simple remote administration. The gallery submission form could put the entries directly into the database, but with a "hidden" flag set. The maintainer could quickly query those with that flag set, verify the entries and clear the flag. > a. I chose Postgres, but mSQL is likely sufficient. Regardless, this For this application, I'd strongly put in a plug for mSQL, or even a perl script that chews up a one-record-per-line flat file. Postgres is quite a load for such a small application; the startup overhead is in particular is a killer. I have a service on my machine that uses postgres and I sure can tell when somebody hits it without looking even looking at top! (http://fallout.campusview.indiana.edu/mapfinder, this databse has records for 310,000 items, and one table with over 1 million entries.) > The sorting order doesn't fold case, so "AZ" is lower than "ab". Also > doesn't handle names starting with "The" properly. The cgi could suck the results into an array and sort using its own algorithm. > create table gallery ( > organization varchar, > description varchar, > url varchar, > category varchar, > contact_email varchar, > date date > ); I'd add another date field "checked". We should be either manually or automagically verifying the entries periodically and that could be useful. Now for the bad news: This scheme presents some problems for mirroring. Unless the system can be easily duplicated (not likely considering many mirrors won't even run cgi scripts), it will be yet another portion of the web pages that people have to trek all the way back to freefall to get, which is something to be avoided whenever possible. Heck, I am at a well connected site in Indiana and have a hard time getting through sometimes! This does not necessairly mean ditching the database idea. Rather, it means generating static copies of the pages during daily regeneration process. Of course, could still a problem for people who want to mirror the web source and generate their live pages locally. Something to think about. -john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.970117141501.22331H-100000>