g. Today's first-generation systems are already useful. Once they break through the four barriers common to all Web applications, conferencing systems will be off and running.
Barrier 1: Installation
Conferencing springs into action with a mouse-click. Any Web browser can run these applications: Users don't have to acquire and install other client software. Administrators, of course, do have to acquire and install the server softwa
re. Web technology doesn't make this job any easier than it ever was. In fact, it's more complicated. You have to deal with the usual paths and permissions, plus a whole new set of paths and permissions arising from your Web server's Common Gateway Interface (CGI) environment.
I put net.Thread on our BSD/OS machine running the NCSA Web server, net.Thread and Web Crossing on an SGI Indy running the Netscape Commerce Server, and Cold Fusion Forums on a Pentium-based NT server running Microsoft's Internet Information Server. None of the installations went like clockwork. But none required more than a little fiddling, either. It wasn't a lot of effort to create a conference that's instantly open to every Web browser on the planet.
Once installed, Web conferencing systems offer spectacularly easy administration. You do everything through a Web browser. Of course, browser interfaces are becoming the de facto standard for all sorts of network administration nowadays. Printers, mail servers, Web applica
tions--anything that lives on a network can benefit from the ubiquity of a browser-based management interface. The Netscape News Server, I'm told, wraps such an interface around the standard INN engine we're running on The BYTE Site. So the administrative convenience of Web-based conferencing isn't a unique advantage.
Barrier 2: Missing HTML Widgets
Management interfaces work well on the Web because they're simple and forms-based. But applications with more demanding user-interface requirements tend to suffer. HTML lacks the advanced widgetry that enlivens modern GUI applications. In particular, it lacks a tree control. Smalltalk pioneered this widget 15 years ago, and now it's everywhere: Notes 4, the Windows 95 Explorer, the Netscape 2.0 mail and news clients.
Because conferencing often involves some kind of forum/topic/message hierarchy, tree controls that enable users to dynamically expand and collapse levels of this structure play an important role. However, Web developers
must attempt to emulate these effects with a series of pages that creates the illusion of accordion structure. This method works--but not too well.
One solution might be Netscape frames. A frame set can express an information hierarchy as a group of linked panels--see
"Web Design,"
March BYTE, for a prototype of a frame-enabled BYTE Site. But frames aren't a panacea. They work only in Netscape Navigator 2.0, and they are tricky to use effectively. Even Netscape's own newly frame-enabled site isn't as easy to understand or navigate as you would like it to be. And because a frame set can include another frame set--even itself--an inadvertently recursive uniform resource locator (URL) creates a disconcerting hall-of-mirrors effect. Perhaps for these reasons, I've yet to run across a frame-based Web-conferencing system, although I'm certain they're coming.
Another solution to the problem would be to add a tree control to the browser's arsenal of widgets. Such a control will surely be one
of the first killer Java applets. Expect an ActiveX OLE implementation of the same idea to emerge from the Microsoft camp. Wielding these components, Web developers will be able to break through the Hypertext Markup Language (HTML) barrier. The user-interface advantage that fixed-function conferencing clients now enjoy will erode. Extensible Web browsers will suffice for conferencing and for many other kinds of applications.
Barrier 3: Stateless HTTP
You'd soon lose patience with a conferencing system that forced you to log in not just once per session but once per message. Yet that's just how a naive implementation of Web conferencing would have to work. HTTP owes much of its huge success to its connectionless (i.e., stateless) mode of operation. That's what enables Web traffic to flow reasonably well despite the high latency and lousy fidelity of a large portion of the Internet. However, HTTP's statelessness greatly complicates applications--such as conferencing--that require persis
tent user identity.
The classic solution to this problem retransmits user credentials on each CGI invocation. Both net.Thread and Web Crossing work this way. Because these systems dynamically generate all the HTML pages that users see, they can insert credentials into the
action=
attribute of each page's
<form>
tag. Hidden fields are another way to achieve the same result. (See
"Perl Magic,"
December 1995 BYTE, for an explanation of how hidden fields maintain state in the Virtual Press Room application.)
A consequence of this on-the-fly generation of pages is that conference messages don't live in normal Web space where indexers can find them. That's a moot point if the system keeps messages in a database anyway, as do all three systems discussed here. But even if messages were stored as plain HTML files, this architecture would hide those files from standard Web indexing and search tools.
Cold Fusion Forums implements an alternative way to create persist
ent user identity. This technique exploits the Netscape cookie, a name-value pair that a server script can create, store on the client, and retrieve on subsequent interactions with the client. The cookie works in Netscape Navigator (which accounts for 75 percent of BYTE Site visits) and Microsoft Internet Explorer (9 percent), but not in Mosaic (8 percent) or WebExplorer (3 percent). Because the cookie remains on the client until it expires, Cold Fusion Forums can remember a user not only during a conference session, but also across sessions.
Systems that use cookie-based authentication typically generate pages on the fly, as do systems that transmit credentials on the CGI command line (or in hidden form variables). The program that writes the HTML pages governs access to them using cookie data that it extracts from the CGI environment.
Can you use cookie-based authentication in an application that's based on a static archive? Yes. Some Web servers, including Quarterdeck/StarNine's WebStar and M
icrosoft's Internet Information Server, can insert filters into the processing of client requests. These filters can inspect and act on CGI environment variables. So you can extract cookie data without having to wrap an entire CGI application around every page of an archive. Of course, the mechanisms are server-dependent.
Barrier 4: The CGI Bottleneck
The 16-MB 486/50 Dell on which INN 1.4 runs happily couldn't handle net.Thread. It was unusably slow. (On an SGI Indy, however, it ran quite well.) Why the molasses-like performance on the Dell? Every user action in net.Thread requires the server to suck in and interpret a big chunk of Perl code. The only way to scale up, given this architecture, is to throw more hardware at the problem.
Net.Genesis says version 2 will rely less on Perl, more on compiled C code. Does that mean an interpreted language like Perl can't break through the CGI bottleneck? Not necessarily. Consider building an application engine in Perl that runs as a da
emon, along with a lightweight CGI stub that transmits user requests to the engine and receives data from it. This architecture will improve any CGI application, compiled or not.
Two compiled applications that take this approach are Web Crossing, whose engine ran as a Unix process on the Indy, and Cold Fusion Forums, whose engine ran as an NT service on a Pentium-based Dell. Web browsers talk to both applications' engines by way of compiled CGI stubs. With the engine always running, the bottleneck becomes the Web server's ability to execute the stubs. Conventional CGI technology requires the server to spawn a process for each stub invocation. That's expensive, particularly on NT. High-performance alternatives are emerging in the form of APIs that enable Web-server-based applications to run as extensions of Web servers.
Cold Fusion Forums supports three of these: the Netscape server API (NSAPI), the WebSite API (WSAPI), and the Process Software/Microsoft Internet Server API (ISAPI). I downloaded
the ISAPI version of Forums (
see the screen
). It replaces the regular stub (dbml.exe) with an alternative one (dbml.dll) that runs in-process as an extension of the MS Internet Information Server. (In theory, it also works with Process Software's Purveyor, although I didn't try that.) Was it faster? Not noticeably; however, our conference didn't generate enough traffic for a real stress test.
Web vs. News
Scanning the sidebar
"Web-Conferencing Benefits and Drawbacks"
, it's easy to see what requirement disqualifies either an HTTP- or NNTP-based conferencing system. Need to cross firewalls? NNTP loses. Need replication? HTTP loses.
It's harder to judge the benefits of each approach because both are evolving at warp speed. Based on the reactions of visitors to The BYTE Site, NNTP wins. But the boundaries are already blurry. Newsreaders are rapidly becoming more browserlike and vice versa. What matters is not how you deploy conferencing, but that you
deploy this vital and underutilized communications tool.
TOOLWATCH
cgi-lib.pl
http://www.bio.cam.ac.uk/cgi-lib/
http://www.mispress.com/introcgi/cgi-lib/
Web Conferencing
