Re: OSF1 to Sybase System 10
A few tips/lessons learned:
Check out GSQL from ftp.ncsa.uiuc.edu...it is a Sybase-to-WWW interface.
It works for the simpler stuff but rapidly becomes cumbersome for more
complex queries. We used an Oracle version of it for a while but
became disenchanted when we had to perform joins (GSQL does NOT support
joins), so we switched to strictly Perl, C-SQL and HTML.
Can't speak for SyBase but for Oracle, connects/disconnects are not
a problem. It is important to run httpd in STANDALONE mode as an
INETD setup has too much overhead for multiple rapid-fire requests.
Efficient interfaces are usually not the problem (the above strategy
works extremely well for us) and the time spent in a) server code,
b) CGI execution, c) database access and d) HTML generation is
usually in the noise level when compared to network response times,
assuming a well-designed database of course!
We basically have a single user (the owner of the httpd
server) who performs all requests on behalf of legitimate users.
We modified Mosaic (X version) and both the NCSA httpd server to
implement an obscure part of the URL spec to include a user's id (which
is generated from a client's UNIX LOGNAME variable that he can NOT
normally modify) within the URL e.g.
(There IS an RFC that supports remote identification but can potentially
double your network traffic and requires an extra client daemon.) The
above scheme allows the server's REMOTE_IDENT CGI script variable (this
server variable is normally set to 'UNKNOWN') to be concatenated to the
REMOTE_HOST CGI script variable to create a compound unique key e.g.
kevin <--> concord6.powersoft.com
into an Oracle USER_INFO 'scratch-pad' table that contains a user's default
settings and other information thus allowing the single httpd server
owner/Oracle user to have knowledge of who is executing a script.
(There is also a default 'adhoc' user-id that allows generic system usage
with reasonable default settings thus avoiding the registration of hundreds
of database users within the database engine.)
This works for us because we have a READ ONLY database (except for
the USER_INFO table!), no user updates are allowed. It also disables
most other WWW browsers that have NOT implemented the above URL spec.
(Including MS-Windows Mosaic unfortunately...I wish the developers would
implement the above URL feature..someone had told me that NetScape seems to
work with the above scheme, kind of!) We actually consider this last
item as a small amount of additional security since we serve a well-defined,
limited user community. An enhancement that we are considering is encrypting
the user-id in the above URL with DES or crypt() just so it is not
plain text. Frank Dreano
On Tue, 18 Apr 1995, Micalizzi, Kevin wrote:
> I'm in the process of generating a proposal for "automating" our WWW Site
> so, for the most part, HTML will be automatically generated based on
> information contained in a Sybase System 10 SQL Server. Some issues I
> haven't addressed yet have to do with finding the most efficient interface,
> and minimizing the overhead of connect/disconnects from the server for each
> CGI script. Has anyone worked with a similar scenario who is willing to
> share with me what you've encountered? Recommendations?
> -Kevin P. Micalizzi