![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Was the first "Server clinic" column serious in advertising Expect as the one language you most need? Several readers have written in since its publication with questions about how far to trust the claim.
The short answer: yes. As the April 2002 column explained, Expect comes closer than any other language to being universal for the sorts of needs system programmers are likely to have with their servers.
That does not mean, though, that you should spurn other languages. My realistic expectation is that everyone who reads this column already knows at least one other language, and that's a good thing. Reader Leam Hall explains a couple of reasons why in a note he posted in this column's discussion forum (click Discuss at top or bottom of this page). Most compelling to him as a system administrator is simply that he can't count on Expect to be available the way sh and even awk are. All UNIX hosts reliably supply these utilities; only a fraction provide Expect "out of the box".
June's column centered on the importance of deployment issues. I certainly understand that to meet an immediate need, it's not practical to install Expect on dozens or even hundreds of hosts. Still, there's a "remote control" technical fix that often helps in these situations. See the discussion forum for more on this topic as well.
Another possible relationship between Expect and other languages is cooperation. I'm currently working on a class that helps programmers who prefer to work in Java, Python, and other languages, but still want the full power of Expect, to combine the strengths of two languages. I'll have more to say on the subject later in the year.
Another reader asked whether Expect can even do such jobs as displaying a bar chart on a Web page through the common gateway interface (CGI). That's an easy one, as it turns out; ten lines are more than enough. The technique isn't well known, though. Moreover, many people mistakenly believe it's specific to coding in Perl.
I know at least eight architecturally distinct ways to put bar charts on Web pages. The most broadly applicable appears to have been invented first in late 1994, after Netscape's version 0.9 beta release in October made the "dilation trick" possible. Although it's not often used nowadays, I continue to find this best combines compatibility with a range of browsers and light server load. Dave Siegel was a Web designer who publicized this and related "single pixel" techniques, while Robert M. Free did much the same under the trademarked name of "GIF*DOT". Also, Mal Sutherland taught single pixel techniques in his Web Development series.
Figure 1. Simple Expect-coded bar chart
The simplest dilation coding yields a result such as in Figure 1. You can write this in Expect as:
Listing 1. Source code for barchart_expect.cgi
#!/usr/local/bin/expect
puts "Content-type: text/html\n"
# This is just an image of a single blue pixel.
set blue http://starbase.neosoft.com/~claird/tmp/blue.gif
puts "<HTML><BODY>
<table border='0' cellspacing='1'
cellpadding='0' bgcolor='#ffffcc'>
<tr valign=bottom>"
set heights_to_chart [list 100 10 30 20 70 59 88 11 66 62]
foreach height $heights_to_chart {
puts "<td><img src='$blue' width='15' height='$height'></td>"
}
puts </tr></table></BODY></HTML>
|
It takes only a few lines more to make the bars "clickable," to add legends, to supply the color through a dynamic calculation, and so on. The important point, though, is to realize that essentially any language -- C, sh, Ruby, certainly Expect, Icon, assembler -- can generate these figures. The next time you need a quick bar chart display, use dilation and your favorite language in a server-side Web generation.
Another capability Expect shares with other server-side languages is construction of Web "monitors."
Have you ever needed to keep your eye on a remote variable through a Web application? You can visit a weather site, for example, and just hit "reload" or "refresh" every few minutes to ensure that the temperature you see is relatively current.
That approach has awful aesthetics, of course. Every time you refresh, your browser blanks, at least temporarily. Rather than that annoying distraction, you want a Web page that stays fixed, and simply updates a single text element or graphic. For example, the visual effect might be to change from green to red when a server load exceeds a threshhold, or to display the three most recently connected telephone numbers, or most recently analyzed protein sequences in a large production process.
While many developers want such an application, and I've
worked out four different solutions, few Web workers seem
aware of how to code such monitors for themselves. The
most satisfying is one I call the "DOM 2 monitor." It
relies on the ability of client-side JavaScript to update
the data attribute of a DOM node.
In this and future "Server clinic" installments, I'll often rotate examples through several different languages. Although I first wrote a DOM 2 monitor in Expect, the instance that follows is in Python, simply to emphasize that the ideas are available for many different languages.
Figure 2. Simple Python-coded DOM 2 monitor
You can see a "live" monitor by following the URL that appears in Resources, below. Notice that most of the page in Figure 2 stays fixed, without any "flashing," while the clock value counts off the seconds at the server. This source code generates the page:
Listing 2. Source code for monitor_python.cgi
#!/usr/local/bin/python
import sys
import time
print "Content-type: text/html\n"
print """
<HTML><HEAD>
<title>Web application 'monitor' demonstration</title>
</HEAD><BODY>
<p id ="x1">Replace me.</p>
<p>You need IE 5.5, Netscape 6, or Mozilla 0.9.5,
or greater, to see this effect.
</body>
"""
print """<script language="JavaScript" type="text/javascript">
myP=document.getElementById("x1");
myTextNode=myP.childNodes[0];
</script>
"""
while 1:
time.sleep(1)
print """
<script>
myTextNode.data = 'The time at the server is %s.'
</script>""" % time.ctime(time.time())
sys.stdout.flush()
|
In this design, the server-side language does only light duty, simply sleeping periodically while sending JavaScript text for the client to interpret. It's the browser that does the hard work, here. Each burst of data requires the browser to update its JavaScript variables and the display they describe.
Yes, Expect solves problems over a broad span. No, you're probably not better off trying to do everything with Expect, especially not if you're already comfortable with other languages. Yes, Expect does CGI, and it specifically can do Web bar charts and monitors in just a few lines. No, Expect isn't the only language for such Web applications; in fact, I've constructed the two examples here so you can adapt them for any language you might know.
Join me in the discussion forum to talk over Web monitors you've built. I've found it exhiliratingly useful to be able to supervise server statuses and display them for others from any location with a Web browser. Variables fit for monitoring include:
- Motherboard temperature
- Measured chemical concentrations
- Intermediate results in massive telecomm circuit tests
- System load
- Accounts currently logged in
- Partial calculations in large simulations
The next few "Server clinic" columns will cover other Web programming techniques specific to systems programming, the concept of a virtual file system, the meaning of "concurrency", and much more.
- Participate in the discussion forum.
- Check out the other installments of Server clinic.
- The .gif color dot
dynamically generates a one-pixel color image with the Tcl
language.
- See a live implementation of Listing 2.
- Learn more about how to use remote scripting to make Web applications dynamic and interactive in "Remote scripting using a servlet" (developerWorks, February 2001).
- Did you know that the WebSphere Control Program is scriptable in Tcl? Read Cameron's article "Tcl for WebSphere Application Server Administrators" (WebSphere Technical Journal, March 2002).
- Learn more about the WebSphere Control Program.
- Find more Linux articles in the developerWorks Linux zone.
