[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.
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:
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 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.
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 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.
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...
http://staff.westlake.com/jamie/software/livewire-sucks.shtml
-- Jamie Flournoy, August 19, 1998