Becoming a GSAC Retailer involves several components, the most important of which is the existence of a dependable, fast, isolated database management system that can be dedicated to GSAC purposes if possible. The second major component is an Apache web server (possibly located on the same machine as the database server) with mod_perl built into it. The third major component is a current installation of the GSAC Perl modules (contained in the current distribution of the GSAC software, available by request from SOPAC). With a fully- loaded, continously-updated GSAC database (one of two types currently supported for GSAC Retailers - Oracle or Postgres), an Apache web server with the mod_perl extension and the Apache::GSAC::handler method registered as a mod_perl "service" on the web server, and a complete GSAC Perl installation, you can begin offering the /GSAC service to the public.

Without a doubt, Retailing is the MOST involved participation one can have in the GSAC, and the most difficult and/or timeconsuming to construct and maintain. The three major components involved in constructing a Retailer service are outlined below. Each component has it's own set of instructions and/or installation process. It is entirely possible, and, in fact, encouraged, that all three components reside on the same server hardware, thereby affording the implementing agency the opportunity to construct and administer their GSAC "service" in complete isolation of the rest of their system if need be.

• Database Server
Though all three Retailer components are necessary to GSAC Retailing (using Perl anyway) the most important is by far the Database Management System. Currently Oracle 8,8i (and probably 9i) and Postgres 7.x databases are supported by the GSAC Perl software. Assuming there are one or more people familiar with and/or responsible for database administration for the GSAC duties of the local agency first and foremost their needs to exist a functional GSAC schema (and associated user accounts) within the database in order for proper interfacing to occur via the GSAC Perl software. Additionally, there is an optional spatial component that requires the PostGIS extension to Postgres or the Spatial Option for Oracle Enterprise Edition. Sample SQL scripts and instructions for creating the schema are contained in the GSAC software distribution under the subdirectory schemas; this is where you should go for more information about the database component, and then email SOPAC if you have further questions.
• Apache Web Server
While the database facilitates ALL of the "backend" Wholesaler->Retailer syncronization and information management, the Apache web server of the local Retailer facilitates ALL of the "frontend" interaction with GSAC users. Since it would not only be painful, insecure, and inefficient to provide the public with direct access to your database, it would be extremely difficult to implement seamlessly across multiple Retailers since each would probably offer different methods for interacting with their own service. Thus, a URI-based request and response protocol has been established to help ensure the seamless nature across multiple Retailers, and to the data holdings and monument catalog information they contain.

For this part of the Retailing "project" one needs to build an Apache web server, with a compiled-in mod_perl extension, and/or utilize a preexisting server (with mod_perl) for GSAC purposes. mod_perl is the critical ingredient here as it facilitates direct communication between the Apache process and the local GSAC database via the GSAC Perl modules. It also ensures faster execution since there is a Perl interpretor built into the Apache process, making it much faster than, say, a CGI-based interface. Of course, the database we're speaking of must be visible and/or accessible from the web server machine, if they aren't one in the same. As for the Apache configuration all that needs to modified is the addition of a few lines to httpd.conf, namely: SetHandler perl-script PerlHandler +Apache::GSAC There are no more instructions regarding this component at this time. Please feel free to email SOPAC if you have further questions.
• GSAC Perl Libraries
The GSAC Perl libraries serve as the glue between the web server and database server, translating requests from HTTP URIs into appropriate methods for the native GSAC::Agent driver. From a Retailers perspective the ONLY modifications required are in their respective gsac.conf file. Although actual functionality, and semantics vary between Oracle and Postgres the methods available to the Apache mod_perl service through the corresponding GSAC::Agent driver are identical. This will allow multiple GSAC Retailers to provide the EXACT same URI-based interface to the public.

This component of Retailing will be installed during the installation process of the GSAC distribution. Please refer to The Perl-related component of the GSAC for more information.

After installation, the operator will edit their gsac.conf file and specify what type of database they are using, how to connect to it through the Perl DBI, what user and password to use during the connection, and what special options their database supports. (see your gsac.conf file for more detailed instructions)

• Database Syncronization (backend)
Assuming all of the above requirements are met, none of this will work unless the given Retailer can 1) populate their database with the entire holdings (monument and data) of EVERY participating Wholesaler, and 2) keep their database accurate and up-to-date with the Wholesalers indefinately. There is one particular utility designed to perform these two functions for a Retailer. The utility is called gsac-sync and it is included in the GSAC distribution under /bin. Using this utility a Retailer can maintain a current GSAC database. It is a system-level script designed to help fulfill the "backend" responsibilities of a GSAC Retailer.
• Web-Based GSAC Clients (frontend)
Last, but not least, users of the GSAC can become familiar with the GSAC, it's function, it's purpose and design, using either a custom application of the Retailer's choosing or the provided CGI Wizard /cgi-bin/GSAC.cgi and/or the command-line utility /bin/gsac-client. GSAC.cgi offers a graphical Wizard interface enabling basic to moderately-complex GSAC query generation and interaction. However, Retailers should stress to their users that the actual "service" can be accessed via non-graphical tools as well; as long as the tool supports the HTTP protocol it can be used to "fetch" GSAC requests in the same fashion as the most advanced graphical web browsers.