CSAP Client/Server Application Protocol

A system for cross-platform networked applications

Russell Holt

Draft #4, August 29, 1995

Destiny Software Corporation

Summary of Features and Benefits
Example CSAP Application diagram Postscript, 48k


Building on the precedent of the World-Wide Web (WWW, W3, web), CSAP is a marriage between the functionality of today's desktop applications and the cross-platform networking flexibility of the web server/browser combination. CSAP is an addition to the W3, not a replacement. A great body of hypertext information already exists and this presentation format is invaluable. For interactive applications, however, it is very lacking. CSAP brings the W3 to new heights of interactivity and functionality.


A web browser gives a graphical view of the Internet. The W3 can be imagined literally as a "web" of documents interconnected by hyperlinks. Most of these documents are written in the HyperText Markup Language (HTML), the page-description language of the W3, and others are files of various media types used in HTML documents such as graphic images or sounds. Some of these documents exist as static files on a server computer, and others only exist in so far as they are generated by programs that process data from HTML fill-out forms.

It is this ability - to generate new HTML documents based upon user input - which has allowed the W3 to grow beyond static information presentation and has helped it flourish to the great extent that it has. It has allowed simple applications to be created which are immediately available on all platforms for which a web browser exists, and can be accessed from anywhere on the Internet. Obviously, this ability is an extremely valuable asset.

But herein lies the problem: the web browser is still just that - a browser. No matter how complicated an application built with HTML fill-out forms becomes, a web browser still can only display one document of static information, whether that information was actually stored as a static file on the server or whether it was generated by a program in a dynamic way.

The W3 has given a glimpse of the possibilities of networked, platform-independent graphical applications, yet the chief limiting factor to rapid progress in that direction is the underlying document request/response operation of HTTP, into which we cannot force-fit the desktop application metaphor.


Enter CSAP, the Client/Server Application Protocol. CSAP builds upon the ideas of and is an addition to, not a replacement of, the W3. Like the W3, CSAP requires client and server software. The organizational unit in the W3 is the document; in CSAP it is the “Application.” A CSAP Application is very much like a desktop application except that its user interface is created within a CSAP Client. This strict division between user interface and application code allows it to be run in multiple environments where the actual user interface elements vary widely and are platform dependent. A CSAP application may have a wide variety of user interface elements, known in CSAP as Objects and may consist of many windows and dialog boxes; icon palettes; multiple cursors; all the standard elements such as buttons, scrolling lists, text input, etc.

A CSAP client is roughly analogous to a Web browser in that it is an all-purpose program that acts as a single interface to the Web and the Internet. The Web browser is a much more simple concept in that its operation with respect to the Web6 consists of simply opening a channel to a Web server; making the document request; reading the response and the document; closing the communication channel, effectively just loading a document. In CSAP, both read/write channels remain open between the Client and the Server for the duration of the use of the Application. This allows immediate interaction that is missing from the W3.

Operation and Implementation

The CSAP Client acts as a standard Web browser using HTTP, allowing it to exist seamlessly with the W3. A CSAP Application may be written as a standard CGI program to be launched from a standard Web server when requested (presumably by a CSAP Client). When launched, the Application takes over communication with the Client using CSAP, and the CSAP client shows its true colors.

A CSTP application is a program written in C or C++. Strict separation of the user interface and its support code is enforced by the division of the application between Client and Server to ease the support of multiple platforms. The program begins by creating its required Objects and registering them with the Client. The Client creates user-interface Objects which mirror those on the server. These Client Objects have a visual representation that is platform specific, and implemented slightly differently in each version of the CSAP browser. The interface to the CSAP Object, however, remains the same.

After creating its Objects, the CSAP Application on the Server waits for messages from the Client. The Client, in turn, waits for user interaction. The true power of CSAP is seen when we realize that an Object can be as simple as a button or as complicated as an HTTP/HTML display Object (that is, a “Web browser”) or a VRML (Virtual Reality Modeling Language) Object, and it is encapsulation and object oriented design which allows us to do this. This is the way in which most “competing” technologies like Java, HTML, HTTP, VRML, etc., can be incorporated into CSAP and a single CSAP Application.

Risks or "If this is so great, why isn't someone else doing it?"

The answer to this question is that they are, except that they are trying to extend/fix the HTTP/HTML system rather than create a better one because they are intimidated by the scope of the web. Potentially competitive systems are as follows:

Imagine what a company such as America Online could do with CSAP: their system could augmented or replaced by an interface which could run over the Internet to "Web" sites (for example) and which would not have to be built from the ground up for each content provider; their entire set of services could be fully secure and completely integrated with the Internet and the W3. There would be no "web browser" versus America Online software; it would all be the same interface. America Online could then offer their services to the entire Internet community and to all platforms which have a CSAP Client - automatically. What would continue to differentiate them from the Internet and other Online Services, however, is that they offer valuable paid services which are not available elsewhere.


All of the technologies which are offering additional functionality and/or interactivity beyond what is offered by the Web today are limited in scope, have inherent technological limitations, and are not even addressing the same problem as CSAP. CSAP breaks the technological barriers of HTTP/HTML and provides an unprecedented level of interactivity to the cross-platform Internet that is nearly equal to that of today's desktop applications. It is different from all other competitive products to date in that it is the only system which brings the functionality and flexibility of desktop application software to the Internet.

CSAP and Related Products

  1. Information displayed in browsers is static One exception is "server push" and "client pull" in Netscape which allow pseudo-animation, but which are not relevant to interactive applications.
  2. Objects for lack of a better term. CSAP needs a good vocabulary.
  3. CSAP Application takes over communication In some cases, this will probably require a very small change to the standard web server to open the read communication channel from the Client as well as the write channel (which is already open to CGI programs.)
  4. C or C++ Required for now; support for scripting languages such as Perl and Java or graphical GUI builders are possible.
  5. Incorporation of HTML etc. An HTML CSAP Client Object has the option to speak HTTP to get obtain its content information or to obtain it from the CSAP Application. What happens when someone starts surfing the Web this way while a CSAP Application connection is open to a server, is an open issue at this point.
  6. Tracking users through a system Difficult in HTTP/HTML because a “system” in the web is a collection of distinct documents which may be requested individually by a client, whereas in CSAP a “system” may be represented by an Application with as many windows as necessary. Tracking a user “through” such a system is trivial compared to the external structure imposed on a set of HTML documents using CGI and URL kludges.