Re: Building a Z39.50 client and server

On Thu, Jun 07, 2001 at 12:39:29PM -0700, Margery Tibbetts wrote:
> We go to great lengths to make the Melvyl Catalog web site
> state-ful (i.e., not stateless). We do that by having a UNIX
> process remain active for the entire user session. When the
> original connection is made to our site, our CGI program
> recognizes it as the first, and it starts the UNIX process. A
> session id is assigned to the process, and any time the user
> clicks on something on the screen, the session id is returned
> by the browser to the web server.

I am jumping in late on this conversation and have not read all of
the previous text so I might be out of context. But we also did exactly
the above many years back. The only problem we had was performance
under load (we had requirements for 800 concurrent users on one project).
The performance problem was only going from a web browser -> web server
-> CGI -> UNIX process -> Z39.50 server and back again. Lots of hops
introducing little delays along the way.

Our final solution was that we developed our own multithreaded web server
reducing the number of hops. web browser -> web server -> Z39.50 server.
Rather than keep a full UNIX process per user session, we keep an in-memory
data structure (with the Z39.50 socket connection to the Z39.50 server)
then create a thread to process each HTTP request on demand. This kept the
overall resource usage down.

We made the web server scriptable so the entire application was in the web
server. Session management (using session ID's in cookies or whatever)
was just the same as before.

This approach was much more responsive, but has a real marketing negative
in that you have to use our web server - you cannot use Apache etc.
It also is more priopretory in that it does not use standard web servers,
CGI, etc. So pluses for performance, minuses on other fronts.

Just thought I would put in my 2 cents worth.

ajk

Received on Thursday, 7 June 2001 20:01:20 UTC