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