Click on our Sponsors to help Support SunWorld

The disappearing line

Documents and client-server programs come together on the Web

By Bill Rosenblatt
SunWorld
December  1995
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
Programming languages and text processing (markup) languages have historically been viewed as two different animals. In this article, however, the author argues that as these species evolve they will begin (indeed, they have begun) to share more and more traits.


Mail this
article to
a friend

Those of us who write columns like these and develop software for a living cannot help but be fascinated by the shrinking differences between the languages we use to do each type of work. The most modern programming languages and tools concern themselves more and more with graphics and user interfaces, while the latest document-creation languages let you create "deep" content that doesn't just sit there on the page or screen. With Netscape's new LiveScript extensions to HTML, the line between the two types of languages may have completely disappeared; furthermore, they make the Netscape web architecture look more and more like a powerful client-server software development platform in disguise.

Programming languages and text processing (markup) languages have pursued totally separate paths for a long time. Yet programming languages have, in a sense, always been capable of "word processing." With any conventional language, you can write lots of print, write, printf, etc., statements and get a document as output. If you know the control codes of your output device, you can insert them in your text to get some formatting or graphics. The C language even contains rudimentary forms of "markup" by providing special notation for simple formatting commands like linefeeds and tabs. You could use simple features of conventional languages to add more markup commands, like this:

#define BOLD_ON "\023a"
#define BOLD_OFF "\023b"

...

put (BOLD_ON);
put ("This line is in bold.");
put (BOLD_OFF);

There isn't much difference between that and something like

\fBThis line is in bold.\fR

Advertisements

It's a floor wax
The former language, C, is capable of much more than document creation, of course, while the latter, the troff text markup language, is meant only for creating documents. Yet writers have used languages like troff, Script, and Scribe, rather than C, because such markup languages are easier to use for producing printed documents. They also abstract away certain formatting concepts that are more advanced than bolding, underlining, or tabbing -- concepts like paragraph indenting, justification, and logical document structure, which cannot be implemented by means of simple control codes.

WYSIWYG word processors are, in this sense, really no different from markup languages; they have merely the added component of being able to see the results of markup on the screen rather than the markup itself. For example, you type CTRL-I in Microsoft Word and the text becomes italic right away. But the functionality of the commands is much the same; WYSIWYG word processors still only let you produce static documents -- at first, that is.

Word processors took their first real leap toward being programming tools with the advent of Microsoft Windows' Object Linking and Embedding (OLE). OLE started out as a way of letting word processor users embed different kinds of objects, such as spreadsheet charts, into their documents. But as it became more pervasive among Windows applications, OLE turned into something else: a general way of integrating multiple object types into one document, i.e., a compound document architecture (see "Enterprise Document Management: From Data to Documents," SunWorld Online, August 1995). One of the object types that can be embedded in many types of Windows documents is a program written in Visual Basic for Applications (VBA). The result is a document with arbitrary functionality built into it.

No, tt's a dessert topping
Meanwhile, Visual Basic -- and other languages used in graphical environments, such as Smalltalk and NextStep Objective-C -- directly address look and feel by their ability to process events and manipulate objects in a window. Those objects, in turn, can include text boxes that the programmer or end-user can format with standard text-formatting features, like fonts and colors. The result, if you will, is arbitrary functionality with documents built into it.

The Visual Basic paradigm approaches the blurry line between documents and application programs. The only difference between a Word (or WordPerfect, or WordPro) document with a VBA program in it and a Visual Basic program with a formatted text box in it -- absent the zillion additional word-processing bells and whistles that those word processors provide over simple formatted text boxes -- is the outermost set of assumptions about the presentation to the user. Documents are assumed to be essentially two-dimensional things with rectangular shapes whose "vertical" dimension goes on arbitrarily long and whose default content is text that flows in the usual way. Application programs, on the one hand, can presumably do anything. Yet their user interfaces look more and more like two-dimensional rectangular things as well. The emphasis in a document is still on the presentation to the user, while the emphasis in a program is often on the "guts" behind the user interface.

Convergence on the Web
But all of that is in the increasingly mundane world of the desktop PC. In the client-server, cross-platform paradigm, documents and programs are looking more and more like two sides of the same coin. The catalyst that brings them together is the World Wide Web. A new programming language from Netscape Communications called LiveScript shows how the boundaries are disappearing. LiveScript is included in Netscape's HTML language for its Navigator 2.0 release, which is in beta now and due to go production shortly. Although the language definition is not quite complete yet, you can get demos and see code in the LiveScript pages on Netscape's web site.

On the surface, LiveScript is like a subset of Java. Both LiveScript and Java use a C++-like syntax with object-oriented class definition, and both languages contain facilities for handling events like mouse clicks, window selection, etc. And Netscape's 2.0 HTML language also supports Java applets, but in a different way, as we'll see.

LiveScript is meant to be used for fairly simple coding tasks that can be intermixed with standard HTML -- i.e., with document content -- without cluttering up the source or adding undue complexity. As a programming language, LiveScript differs from Java in three important ways. First, it is a purely interpreted language: whereas Java programs are compiled into byte-code and then sent over the net to the client, LiveScript programs exist as source code on the HTML page and are interpreted by the client, Netscape Navigator. Second, although LiveScript is object-oriented -- it supports objects, methods, and properties -- it does not support class extension (inheritance).

Third, LiveScript is not strongly and statically typed, as Java is. Strong typing means that programmers cannot take an object of one type (an integer, say) and use it as if it were another (e.g., a Boolean value or a memory address). Static typing means that an object's data type is decided at compile time and cannot change during runtime, even with explicit casts (type changing operations). Java incorporates strong and static typing for two important reasons: security and efficiency. It prevents Java programmers from being able to "escape" the Java interpreter's language environment and do damage to the client's system. It also makes Java easier to compile into efficient byte-code that is smaller -- meaning that it takes less time to send over the net -- and faster to run.

LiveScript's lack of strong typing may raise security concerns: a problem that has certainly stung Netscape in the past. Surely Netscape is very sensitive to this issue by now and will address it properly by the time LiveScript is finalized. But otherwise, LiveScript's design is appropriate for its purpose: simple programming that is meant to be intermixed with (hyper)text formatting in HTML.

In the context of this article, the real difference between Java and Netscape HTML/LiveScript is that the latter is an integrated language, while Java is a language environment separate from HTML. In one sense, HTML with LiveScript is like a text markup language with a very powerful "macro" language built in. Its emphasis is on page design with small support applications added in later, while Java's emphasis is on the applications first, the page layout second. To use the Microsoft example above, HTML/LiveScript is more like Word with VBA, while Java is more like Visual Basic itself.

HTML as programming language
But when you consider what the architecture of the web does for you implicitly, you'll realize that HTML/LiveScript is really a powerful client-server rapid development tool waiting to happen. Think about the requirements for client-server application development: you need to be able to build functionality on both client and server sides where appropriate, and you need some reasonable method of communication between them. The web gives you this for free.

Standard HTML (without LiveScript) gives you a reasonable amount of functionality on its own. It lets you build look and feel of the user interface by placing formatted text and graphics, and it gives you a decent set of controls to pass on to the user through forms and their widgets, such as fields, check boxes, and list boxes. Hypertext links turn out to be a reasonable substitute for multiple window manipulation: clicking on a link is like creating a new window, and the "back" and "forward" arrow buttons on most HTML browsers are ways of changing your window focus. Netscape's HTML has added a few bells and whistles to this set, such as table formatting and (in Navigator 2.0) a tiled window-partitioning scheme.

The web architecture gives you other important features for client-server development: it includes protocols like HTTP that abstract away many of the grungy details of TCP/IP communication; HTML is a simple language to develop in -- simpler, I would argue, than the Visual Basics and PowerBuilders of the world -- and best of all, your resulting client code is automatically guaranteed to go cross-platform on Unix, Macintosh, and all flavors of Windows, without any portability issues. Wow. With that feature alone, Netscape may be on the way to putting cross-platform development tool vendors like Visix, XVT, and Zinc on their collective guard.

Yet standard HTML does have significant shortcomings as a client-server development tool. These exhibit themselves in two areas: the amount of processing that you can put on the client side, and the richness of communication between client and server. With standard HTML, all of the serious computation must be done by the Common Gateway Interface (CGI) program on the server, making the client a sort of "dumb terminal" type user interface -- much like the earliest client-server systems.

As for client-server communication, it is done in two ways. The simple way is through hyperlinks that tell the server which HTML page to fetch next. The more interesting scheme is through data passed to the server from forms on an HTML page. This data is typically in the form of lists of variable names and values. The server-side CGI program interprets these and can use them to build HTML pages on the fly to send back to the client.

The forms/CGI scheme is quite flexible but has two major drawbacks: one, it is really only one-way -- HTML pages cannot receive information back from the server and act on it; two, it is semantically weak and requires lots of ad-hoc CGI programming effort to set up correctly. Compare this to client-server communication using SQL with relational databases: SQL queries are semantically rich; SQL engines automatically know how to process them, and they pass query results back to the client program.

LiveScript solves some of these problems by allowing you to put code on the client side that allows the browser to update a page in place, although it still doesn't allow any communication from the server back to the LiveScript program. Also, LiveScript isn't really powerful enough to let you put heavy tasks on the client. You could, of course, write aribitrarily large programs in LiveScript. But because LiveScript is interpreted, you would have to send the entire source code over the network from the server to the client every time, and the browser may take a while to run the code. Therefore, LiveScript is most appropriate for local page updates like the Mortgage interest rate calculation example on Netscape's web site.

Netscape Navigator 2.0 provides for much more powerful client-side functionality through Java applets. Netscape has chosen to integrate Java applets into Navigator 2.0 HTML with a "plug-in" feature that also will allow incorporation of QuickTime videos, Adobe Acrobat page viewing, and other advanced media types.

Yet despite the limitations, the Netscape 2.0 architecture provides substantial client-server development power. And Netscape and other vendors are adding more all the time. The biggest opportunity lies in the ability to handle applications that use relational databases on the server. Tools are needed that allow communication of data queries from client to server -- and query results back to the client -- in a way that minimizes programming, simplifies communication, and maximizes what you can do with the results on the client side. In other words, web development tool vendors need to set their sites on the PowerBuilders of the world. They are doing so, and we'll see how in next month's column.

in the meantime, Netscape's Navigator 2.0, with LiveScript, strikes an impressive balance between document-oriented software development language and "deep content" authoring tool. It points the way to a future where there is no difference between authored content and developed software. Now that's what I call "convergence."


Click on our Sponsors to help Support SunWorld

Resources

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-12-1995/swol-12-cs.html
Last modified: