Previous Next Contents

16. Web Database Design/Implementation tool for PostgreSQL - EARP in the directory 'pub/unix/earp'.

The extract from the home page of EARP is given below:-

The "Easily Adjustable Response Program" (EARP) created by David Dougherty

16.1 What is EARP?

EARP is a Web Database Design/Implementation tool, built on top of the Postgres95 database system. Its functionality includes:

16.2 Implementation

The main implementation of EARP is a CGI binary which runs under the http daemon to provide access to the database server. All of the design tools are built into the driver, no design takes place over anything but the web. The tools themselves require a graphical browser, the compatability of objects designed with the tools is implementation independent, based on designing individuals preferences.

16.3 What you need to run EARP

EARP will likely run on a variety of platforms with little or no porting. The known working platforms consist of the following:

16.4 News Flash

The current (1.3) release of Earp was designed on top of the libpq release that came with Postgres95 v1.01/1.02. If you are using a more recent version of Postgres, expect that the program will require some porting to work correctly. In the development version (Earp 2.0), libpq support is being incorperated as a module, and thus will support as many versions of postgres as we have time to write the modules. The development release is expected to become public near mid-spring(97).

16.5 How does it work?

One of the main features of EARP is that it uses an Object Oriented approach to producing html pages which interface to the database. Most pages will consist of several objects. Each object is produced by some sort of tool and given a name, objects are then linked together in a callable sequence by the page tool. Objects are also reusable across multiple pages. Basic tools exist for HTML, Querys, Grabbing input from forms, Extendable Formatting of Query and Input objects, and Linking together of objects into other objects. More advanced tools include the mail tool and the multithreaded query tool.

Another feature of EARP is advanced security. Access to various areas of the EARP system can be limited in a variety of ways. To facilitate its advanced security, EARP performs checks for each connection to the system, determining what ids and groups the connecting agent belongs to. Access to areas is defined seperately, and the combination decides if access to a specific area of Earp is allowed. Moreover, all that is required to implement the security features is an http server that supports basic (or better) user authentication.

16.6 Some online examples

As part of the ICC Help Database, the Catalog Search Page is an EARP document which runs several queries. The selection boxes are generated by the EARP program from listings in the database.

As another example of what can be done using EARP... now you can look at the List of Objects in the Help Database.

Creating the three interfaces for the link took me less than 15 minutes.

16.7 Where do I get it?

EARP is available via anonymous ftp from in the directory 'pub/unix/earp'. The version as of this writing is 1.3.1

Please, once you've retrieved EARP and gotten it to work, drop me a line and tell me your success or failure story.

16.8 Available Documentation

All documentation has been moved to the User Docs and Tutorials index page.

16.9 A History of EARP

Earp 0.1 began in Fall of 1995 as program I was working on to build a dynamically configurable web accessable guest book. At that point it was a bunch of cgi programs that all did different but usefull things and were held together with SSI glue, and a little sneaky c programming. What I soon realized though is that I was doing a lot of repetitive work, and that most of what I was doing had to be run in many windows at once (netscape, emacs, shell, mail) for it to make any sense, and that debugging was quickly becomming a nightmare. At that time I was also being approached by my friend and boss Don Michaels, who was interested in automating a large hunk of our user support, and keeping a historical database of requests and responses.

Soon, I had worked out the initial scheme for what is now quickly becomming our help database, only I balked at the idea of building a help database with what was at that point a very primitive set of utilities. When spring classes were occuring(96) I started it anyway, mainly out of boredom, but also because I was in a database design class and a wanted to flex a few brain muscles. After a while I had a reasonable prototype up and running, which made Don very happy as he had basically given up on the idea of anyone every really creating a help database for him. (The protoype is still running on one of my servers...(june96)) The prototype did some very interesting things, but by april I was again getting discouraged... Everytime I wanted to change something, I had to go through a lengthy process of recompilation, or find an entry in a text file full of distractions. Also, there was no way for me to use the building block idea which is so usefull in EARP... I did a lot of huge cutting and pasting. About the time that classes where ending I had again given up on the current scheme of things, and decided that what I needed was a better set of tools for what I was doing. Additionally, I also wanted to make my prototype work on top of a REAL realtional database, and I wasn't cherishing the idea of reworking all those hard coded accesses, links, and output methods.

I had a break for a short while, if you want to call it that. We sponsored the SUNY CIT Conference and I was so busy for about a week and a half that I got distnaced from most of what I had written for the prototype help database, except the ideas I had had when I wrote the initial series of utilities, and what my biggest peeves were about the current state of things.

Shortly after the conference, I began the prototype for the current version of EARP(may96), using the postgres95 database as my relational backend. By the middle of June, the prototype had evolved into a fairly nice integrated suite of tool prototypes, with the primary advantage that they all ran over html, and stored their initialization information in the database. Most of the second half of june was spent debugging and working out the kinks in the code, and playing with the interface.( within those two weeks I accessed our web server over 5000 times.) By the end of June I had most of the major bugs blasted out of EARP, and a large enough number of objects in the "new" help database to officially announce it to our help support staff.

Incidentally, I also kept a journal during the development of EARP, and myself and Don Michaels are presenting a paper describing the Help Database at the Chicago ACM/SIGUCCS conference in September of this year.

Previous Next Contents