David W. Eaton
Artronic Development
4848 E. Cactus Rd. - Suite 505-224
Scottsdale, Arizona 85254
602-953-0336
dwe@arde.com
http://www.arde.com
April 1998
My last year's InterWorks presentation, Web Site Secrets looked at some of the specific tricks and techniques used on the InterWorks Web site (now retired) and touched on some automation and interactive features of that site. This year I will broaden the scope of sites considered and delve deeper into automation and the use of the Web for productivity improvements and practical business and system administration applications. Specifically, I will discuss:
No technical presentation about the Web would be complete without references to the specifications, so let's get that done early.
The HTML 4.0 Specification was endorsed as a W3C Recommendation by the World Wide Web Consortium in December 1997. This is intended to be a replacement for HTML 3.2 (January 1997). It offers more new features (such as LABEL, OBJECT, and OPTGROUP) while other features are deprecated (such as CENTER and FONT). You'll want to read through the specification to get all the details.
In addition to the HTML specification, in February, 1998 the W3C issued Proposed Recommendations for both Extensible Markup Lanugage XML 1.0 and for the XML application MathML. It appears Web technicians will have their hands full ensuring products and pages comply with the still emerging standards. XML tools and validation services already are beginning to be available to help.
Most of us have probably filled in Web forms for fairly simple tasks, such as providing feedback in the form of an e-mail message sent behind the scenes. Somewhat more involved are responses to surveys (such as those which have been performed by Interex) where the submitted data is formatted so it may be sent directly to an analysis application. On-line shopping cart applications track your selections from page to page, then total your purchases and take your order.
Having a Web-based business, it should not be surprising that I tend to use the Web as a method to distribute project proposals and even contracts. Not unlike others, sometimes I have sat before the keyboard with a phone to my ear discussing changes to a proposal. However instead of ending the conversation with "I'll FAX that right over to you", I merely say "OK, do a reload. How's that look to you?" The client sees the new proposal or contract wording through a Web browser. If changes are still needed, I can make them immediately and repeat the cycle. Once approved, the contract can be printed locally, signed, and mailed so we each have the obligatory hard copy for our records.
Connections with databases has allowed customers to track package deliveries and freight shipments over the Web. Some banks are begining to offer Web-based interfaces for on-line banking.
Web applications may be growing even more rapidly within the privacy of a corporate network, but most of us cannot see these implementations.
Early applications included Web front-ends to access internal applications such as problem reporting systems. This offered access to these applications for users on platforms which previously did not support interfaces to them.
Frequently Asked Questions (FAQs) are another popular business use for the Web. They enable users to find answer their own simple questions, freeing up senior administrators and other support people to address the more difficult problems.
As might be expected, Web-based applications sought Web interface solutions for themselves. For example, Netscape's Web server administration is accomplished through Web forms.
Now applications and implementations are being created for a wide variety of internal business situations. Increased use of Web database accesses allows managers to update personnel records and do salary planning through Web interfaces. Internal project records, designs, and policies are being made available on both static and dynamic, data-driven Web pages.
If you already have information in a database but need a method to interface that with your Web site, consider using a package such as DBI - The Database Interface. which has standardized the interface to a number of commercial and freely available database engines. With such a package, creating the interface is not particularly difficult. Furthermore, if your site decides to migrate to a different database engine, your Web interface will still work, it just requires a change to the "back-end" DBI uses. DBI is available at the Comprehensive Perl Archive Network (CPAN) and its mirror sites.
You say you have data but can't afford a commercial database engine? Consider the freely available and free engine PostgreSQL. It is a robust Object-Relational DBMS derived from the Berkeley Postgres database management system. Binaries for some platforms are available, but you may download the sources and build it yourself if needed.
Some of you may recall W. M. Richards' InterWorks '95 presentation "Simple Cross-Platform Network Status Monitoring Using Perl". At that time he had a text and Tk GUI interface to the results of the network analysis performed by a perl script. In addition to other improvements, he has added a CGI interface which can interrogate the "ALERT" perl state-daemon and construct a Web page to display the current status information.
![[ALERT status display]](Images/alertdisp.gif)
Each monitored item is displayed on its own line of a table, followed by an indication of its status. The top of the page shows whether all are OK or a count of how many failed. This permits monitoring of a variety of different platforms from a Web browser on whatever desktop you have available.
Elsewhere, Web interfaces have been built to analyze the license status and configuration of ClearCase VOB and View servers and make appropriate recommendations for cache size changes and other tuning adjustments to improve performance. With the Web interface, these critical resources can be monitored over the Web even when the administrator is off-site, providing access behind the fire-wall is available.
Linuxconf is an administration system for the Linux operating system. It may be used to start or stop daemons, to configure a network interface or route, and to mount volumes as well as to perform several other tasks. Its interfaces are: text based, graphical, command line, and web. (It even handles the http protocol itself so you don't need to set up a Web server first.) Licensed under the GPL (GNU copyleft) model, Linuxconf is freely available.
Cobalt Microserver recently introduced the Cobalt Qube[tm] microserver, a simple server in a 7.5-inch cube starting under $1,000 which is targeted at the traditional personal desktop file sharing and Web server market. I won't go into all the product details, but the particulars of its OS (Linux 2.0 on a 64-bit MIPS RISC processor) are hidden from the user and administrator. Installation and administration tasks are performed through a Web browser which communicates with the Cobalt Qube's Apache Web server.
The Web application and automation used to submit and manage the InterWorks conference sessions and build the on-line agenda pages was described in my 1997 presentation. This year, an enhanced version of that same application is being used for both InterWorks 98 and for HP World 98. Configuration files control the features which are different between them, such as track names and certain information used for one conference but not the other.
For performance reasons, conference staff use the tool to build a static agenda page which can be delivered quickly to readers. After readers have made their personal selections, their form is submitted to the same tool. This time, it recognizes that it must save the submission data and display the analyzed results back to the reader's Web browser.
Interex uses another Web application to submit, edit and display the index and individual Web pages for Local User Groups and conference Exhibitor profiles. As with the conference application, configuration files drive the features implemented for each of the implemented cases.
Since a Local User Group may have any number of leaders, when the application retrieves the information previously stored, it adds templates so the information for two more leaders may be entered. Once filled in and submitted, two more entry blocks are provided on the next edit. A similar dynamic allocation is used to allow "growing" agenda entries and a list of dates of future meetings.
![[Local User Group editing]](Images/lugmtgedit.gif)
A pull-down allows the editor to select an optional "new" or "updated" graphic splash to highlight meeting changes on the generated page:
![[Local User Group page]](Images/lugmtgpag.gif)
Using these techniques, any of the authorized staff members or volunteers can create an updated version of a page and post it for you immediately -- without the webmaster being a bottle-neck in the process and without the staff needing to understand HTML or particular document structures, style guides, or local header and footer conventions.
To help ensure the editor is an authorized person, this application utilizes a password on both the static introduction and help pages and on the CGI script itself. By requiring authentication on the script itself, the logic can discover who is using it and tailor the entry fields accordingly. In this way, local office administrators can be permitted to delete an entry and can be granted rights to change more data fields than are offered to an authorized Local User Group leader.
Have you ever used a phrase such as "I'll overnight it to you" when the information being sent was not highly sensitive? If so, consider using the Web to deliver the information. If needed, it may be placed behind a password scheme to keep it out of the hands of search engines and the general public. Alternatively, you can set up a Web server on a port other than the normal default and be certain that your reader knows how to access it. Not only is the Web faster for such deliveries, it is considerably cheaper! Reviews can be performed much more quickly and updates can be made available to all, perhaps even several times during the course of a teleconference!
Do you have difficulty locating the latest copy of official procedures or is your e-mail copy list nearly as long as the weekly status report you distribute? Have you considered e-mailing a document but not all recipients have access to the same authoring application you use? Have you been concerned about the network bandwidth required to e-mail a half-meg or larger document in word processing format? Consider using the Web to automate your business practices in these situations. Post the material and let those who require it access the Web page when they wish. If needed, a brief e-mail message containing the URL may be sent to those needing to review the material. (It also helps that HTML versions of documents often tend to be much smaller than their native word processing format counterparts, thus saving network bandwidth.)
This method provides the additional benefit that when someone new joins the team, you don't need to get copies of stacks of paper. All you need to do is refer them to the information on the Web and say "It's in there."
Take a look at tasks you wish you could access from different platforms or from remote locations and consider how you might utilize the Web to simplify some of your daily activities. Implementation may not be as difficult as you thought and the payback may be many hours of saved labor.
Particularly if you are going to place strategic documents on the Web or create involved CGI applications, you will want to consider using some sort of configuration management (CM) system to help control the various versions and revisions. If you select the freely available package CVS for this task, you may want to take a look at its Web interface, CVS Web. Web interfaces are available or being developed for other CM systems as well.
If the data which drives your page content may be changed, but those changes occur infrequently, you might want to consider generating static pages from the otherwise dynamic data. In this manner, the overhead of the database access or template preprocessing is removed from the far more frequent task of delivering pages to readers. The additional processing required to create the HTML pages to be delivered is done only once, when the data changes and the static page is delivered to your readers many times. The Local User Group pages discussed above are examples of such pages.
If you are using server-side includes to provide common page headers and footers, your computing resources are being used to parse every line, open multiple files, and insert the included data each time someone fetches a page. Since most pages on a large site change infrequently, you are trading what may be considerable compute power for a bit of disk space and a means to preprocess the pages.
If your master Web pages are already stored in a CM repository, such as CVS which was mentioned above, consider "building" your Web via a makefile mechanism. In this way, you can store the pages without your full headers and footers then have the "make" preprocess these files to include the required data and store it in the location required for public delivery. A further advantage is that your testing may be done on the CVS controlled version so the public does not see your incremental changes. Once all changes have been implemented, the "make" can deliver them for public viewing all at the same time.
I still cannot predict that. I'd like to think more browsers will implement HTML 4.0 and XML features, support the lossless Portable Network Graphic (PNG) format, and be available on more platforms. The style sheet feature included in HTML 4.0 is important, finally allowing page appearances to be implemented without force-fitting other tags and perturbing the structure of the document to try to gain a particular visual rendering. Style sheets need to be endorsed by all browser and authoring tool creators and by Web page designers.
Page designers need to realize that
constructs <FONT>
and <CENTER> (among others) have been
deprecated and should not be used.
For the most part, the current generation of HTML authoring and conversion tools are inadequate. They generate such poor, non-specification compliant results that browser developer teams have routine discussions concerning how to display the broken HTML showing up on so many pages. This trend needs to be reversed.
The industry and media need to recognize that there is not a "browser war" to be won. Continued attempts to have one winner rather than a choice of products adhering to standards will result in us all being losers.
There is reason to hope for a better Web environment! At this writing, Project Mnemonic has issued its long awaited alpha release and the Lynx development team is nearing completion of a version which is Y2K ready. By the time of the InterWorks 98 conference, the first developer release of the source code for Netscape Communicator (due on March 31, 1998) should be available via mozilla.org. In addition, there are a number of other browser projects in various stages of completion. With some good authoring and converting tools, Web technology should be in much better shape.
This presentation was prepared by Artronic Development for the 1998 InterWorks Conference. An outline and an abstract are available for your convenience. This is an HTML document located at URL "http://www.arde.com/Papers/AutoTasks/paper.html".
To learn more about the Web, please refer to the other papers which are also on this Web site.
(Dave Eaton has been creating and maintaining Web sites since mid-1994 and performs the "webmaster" function for the InterWorks and other Web sites.)
![[Available Papers]](/Images/ToPapers.gif){kind=small}
![[ARDE Home]](/Images/ToHome.gif){kind=small}
(Updated 20 APR 98)