Netscape LiveWire

reviewed by Philip Greenspun for Web Tools Review

[Note: this page has been superseded to some extent by Chapters 6 and 12 of Databased Backed Web Sites.]

Netscape LiveWire is a standard component of the Enterprise Server 2.0. The purpose of LiveWire is to provide a safe and relatively simple server-side programming environment with efficient database connectivity. In this respect, its aim is comparable to that of the NaviServer (AOLServer) Tcl API that was introduced 1.5 years before.

Programming Cycle

Let us consider this from a project perspective. Suppose that three graphic designers have been working on a Web site for two months. They've built a directory on our Web server of 30 .html files. Then they call in a programmer to add a dynamic page or two, perhaps one that talks to the database.

If this were done with the NaviServer TCL API, the programmer would add a file, say "contest.tcl", to the directory and add an anchor in a .html file to reference it. The next time a user clicked on the anchor, the NaviServer would run the tcl program.

If a graphic designer wanted to fix a typo in a .html file, he or she could do that via Fetch or Netscape Gold or any other tool. If the programmer wanted to fix a typo in the tcl program, he or she could edit that program with a few keystrokes in Emacs (standard Unix text editor) and save the file. The next time a user asked for the .html or .tcl file, the new version would be used.

For a file that is almost all static HTML but needs a little server-side computation, the NaviServer's server-parsed HTML feature allows a magic HTML tag to call a Tcl function on the server. Again, changes to the .shtml file are immediately reflected in a reloaded page.

Under Netscape LiveWire, any page that requires server-side computation must be wrapped up into a "LiveWire application". A programmer can add JavaScript inside <SERVER> tags to any of the .html files. However, these aren't parsed by the Enterprise Server on the fly. The LiveWire application has to be compiled (via a shell command or using the Netscape Site Manager tool) into a .web file. Then the programmer has to go into the application manager (an administration Web page) and load the application into the Enterprise Server.

Painful, but now everything works.

Suppose now that a typo is discovered in dynamic page. The graphic designer edits the file as always and reloads the page. Nothing is changed. That's because the .html file was distilled into a .web compiled object.

So the graphic designer asks the programmer to recompile the application from the Unix shell and/or figures out the Site Manager program and recompiles the application. Upon reload, the page is ... unchanged!

The Enterprise Server is a running C program. It has loaded the byte-code compiled .web file into its memory and will not reexamine the .web file ever. So someone has to go into the application manager and say "restart this particular application."

So what used to be a few keystrokes in Emacs or Netscape Gold now requires three steps:

  1. edit the .html file
  2. recompile the .web file
  3. restart the LiveWire app from the appmgr
Side Note: Netscape's application manager program seems to contain some JavaScript for the client that isn't implemented in the latest Navigator Gold for Windows 95/NT. This always causes warning messages and sometimes causes Navigator Gold to crash altogether.

Programming Features

LiveWire's JavaScript API lacks many of the fundamental features that you'd want as a programmer. You can't call a function to send email. You can't call a function that will go out on the Net and grab a Web page from another server. Thus, most of the interesting Web applications, e.g., an email reminder system, that you'd want to build are not feasible in LiveWire. [Note: Netscape is supposedly going to rectify some of these deficiencies in the 3.0 version of the server.]

One nice feature about LiveWire is that there is a lot of infrastructure for maintaining per-client state. Netscape has developed a fairly clean hierarchy of what they call objects (really just data structures). There is a request object that contains data from the form that the user just submitted and other information that might vary per request. There is a client object that contains data intended to persist for a client's session. There is a project object that persists for as long as the application is running and a server object that persists for as long as the server is running.

These objects provide a natural and simple way to maintain state. For example, if an application has to compute something with a very expensive database query, it could cache the result in the project object. Setting information for a client session is very straightforward as well. You can just say "client.session_id = 37;" and the server will remember.

The semantics of client objects are good, but Netscape's implementation of them in LiveWire 1.01 is abysmal. You have several choices for maintaining these. What you'd think would be the best way to do this is to hold them on the server and then reference them via a unique key stored either in a magic cookie or encoded in the URL.

Netscape actually provides this method, but they provide it in an incompetent fashion. The documentation refers to a server-side "database" of these objects but it isn't a real database management system like Oracle. When a page wants to get client object information, LiveWire "checks out" the entire object and subsequently denies even read access to these objects to other pages. This avoids bugs due to lack of concurrency control, but it means that the client object is unusable for many applications. Two subframes of the same frame, for example, cannot both get client object info. Or if the user decides that one db-backed page is too slow and opens another browser window and uses that to connect to another portion of the same LiveWire app then the second connection won't be able to get to the client object data it expects. This will probably result in a server-side error.

If you want stuff to work, you probably have to set LiveWire to ship all the data back and forth to the client with every page access using magic cookies. This has several disadvantages. The first is speed. You are transporting potentially many Kbytes of data back and forth across the network gratuitously. The second is flexibility. Browsers aren't required to store more than 20 cookies for a particular path so you can't have more than 20 client object variables. I don't think the programmer even gets a warning when this number has been exceeded and information is being lost. One of the most serious objections is that confidential information may have to be sent back to the user. Netscape's examples include scenarios where the RDBMS username and password are stored in a client object. One certainly wouldn't want these residing in a random user's Netscape .cookie file. Or even private information that the user has supplied, e.g., credit card number. A side effect of using a Web site shouldn't be that the user's credit card number ends up stored back on the client computer (which might, for example, be a public machine in a library).

Database Connection Management

Database connections are handled far less efficiently than on the NaviServer. NaviServer allows you to set up a reasonable number of simultaneous connections for the database, e.g., 8, and then all the users share those connections. This results in a basically stable server because the number of processes remains constant. Netscape's basic model is "one user of a LiveWire application = one database connection". This means that the server is forking fairly frequently as users come and go on the site. You might even have two or three database connections for a single user if you don't want to have your whole site be one monolithic LiveWire app.

Database vendors like Oracle are still living in the 1980s when it comes to their C libraries which aren't "thread-safe". Unfortunately, the modern way to build Web servers is not with Unix multiprocessing but with threads. NaviSoft dealt with this rather elegantly by adding some locks to the Illustra C library and then writing external driver processes for other RDBMS vendors. Netscape deals with this by saying "one Enterprise Server process will only have one connection to the RDBMS". So that means you have to carefully set up your Enterprise Server to have lots of processes and very few threads per process. In the end, if you have 100 users interacting with your server, you'll have 100 Netscape Enterprise processes spawned plus 100 RDBMS server processes spawned. Your CPU and memory vendor will be very pleased indeed with this server load requirement. You'd probably be able to handle the same number of users with NaviServer with 1/4 or 1/8th the server horsepower.

Depending on your licensing arrangement with the RDBMS vendor, you might find that it costs a lot of extra money to have hundreds of simultaneous connections rather than a handful.

If you are running Windows NT, the situation is a bit different. Enterprise Server runs as only one process on NT and relies on database vendors producing thread-safe libraries. Unfortunately, Informix (the database bundled with LiveWire PRO) didn't get with the program. Their library is not thread-safe. Hence each Livewire application can only keep one connection to the database open at once.

Bottom Line on Programming

Netscape remains deeply confused about what server-side programmers want. Their idea with their 1.0 server API was that everyone is a C programmer who wants to engineer a software system, run a C compiler, and play with server configuration just to get one dynamic page working. Alternatively, that everyone is incredibly rich and doesn't mind buying an 8-headed DEC Alpha with a gigabyte of RAM to support all the overhead of CGI.

With LiveWire, they've replaced C syntax with arguably simpler JavaScript syntax, but the activity of the programmer is still the same. He's engineering a system, running a compiler, telling the server to restart his program. Because many basic functions have been left out of the JavaScript API, the programmer is forced to learn and use another programming language, e.g., C or Java, so that his little dynamic page can send some email or grab another Web page off the Net.

Another sign that LiveWire is not a programmer's dream is that none of the simple example applications that I distribute for NaviServer would be implementable in LiveWire. The Bill Gates Personal Wealth Clock is out because it has to grab a couple of subsidiary URLs using ns_geturl. The bboard and mailing list apps couldn't be done in LiveWire because they require ns_sendmail.

The Other Livewire

Confusing, there is an entirely separate product that Netscape also sometimes calls LiveWire. The actual application is called Site Manager. If you are able to run it on the physical box that is also the Web server, it seems to be a useful program. It does things like verify internal and external links and lets you view your site in various graphical ways. If you run Site Manager on your desktop machine and try to manage a site that resides on your Web server, it won't do anything until it copies all the files onto your desktop box. Then you can "manage your site" for awhile and copy all the files back. This could be quite slow on a site like mine (2 GB of data) and introduces a serious version control problem. If you copy over the entire site to manage it and then your colleagues change some of the pages on the server, you'll destroy their changes when you save the site back to the server.

Nice Things about the Server

While installing the Enterprise server and reading through the dead trees documentation, I discovered a couple of other integrated features. The report generator is convenient to use, albeit not very flexible compared to public domain standalone log analyzers. The site indexing option looks good, but I don't see why it is more efficient or even much easier to install than Excite for Web Servers (from Architext).

The really interesting extra feature seems to the site catalog option. It will prepare static lists of all your HTML pages sorted by last modification date, title, etc. If you add META tags to your docs giving a category or an author, the program will be able to sort by those tags. Unfortunately, the catalog option is not very flexible. For example, if you don't have any docs with META tags, it does not suppress the option for the user to look at docs by category or docs by author. The option is there but the page served is blank. It would be nice to be able to customize the look of these pages.


Reader's Comments

I spent 18 months doing LiveWire development and it is pretty lame. I hit the wall of scripting languages' limitations quickly, and even though LiveWire in Enterprise Server 3 added a lot of stuff, it still sucks.

For this reason I have dedicated a whole page on my personal site to describing why LiveWire sucks...

-- Jamie Flournoy, August 19, 1998

Add a comment | Add a link