<Introduction>

About the `<bigwig>` Project

<bigwig> is a high-level programming language for developing interactive Web services. Programs are compiled into a conglomerate of lower-level technologies such as C code, HTTP, HTML, JavaScript, and SSL, all running on top of a runtime system based on an Apache Web server module. <bigwig> is a descendant of the Mawl project but is a completely new design and implementation with vastly expanded ambitions.

The <bigwig> language is really a collection of tiny domain-specific languages focusing on different aspects of interactive Web services. These contributing languages are held together by a C-like skeleton language. Thus, <bigwig> has the look and feel of C-programs but with special data- and control-structures.

A general description of <bigwig> can be found in the paper The <bigwig> Project.

The Runtime System

A <bigwig> service executes as a stand-alone process on the server, communicating with the Apache Web server is through a dedicated runtime system. An essential feature of <bigwig> is that services are session based: Web services are not viewed as collections of pages (as ASP, PHP, or JSP) or scripts (as CGI), but as potentially complex sequences of interactions between servers and clients. The control flow (also called the service logic) is explicit in the program source and not defined by chaotic links between pages and links as in many page based solutions. A clear control flow makes Web servic development and maintenance easier, and it also opens up for advanced domain-specific whole-program analyses, as described below.

Furthermore, the runtime system model allows sessions to be bookmarked, paused, and resumed later (as opposed to most CGI-based solutions). Also, the browser's "back" button will function appropriately and not lead to a sequence of obsolete HTML documents resulting from previous session interactions. Finally, the client is ensured some response within a few seconds. If the awaited response page is not ready within 5 seconds, a reason explaining the delay can be given.

The first version of the runtime system is described in the paper A Runtime System for Interactive Web Services. (That version was implemented on top of CGI, and not as an Apache server module.)

Dynamic Documents

In <bigwig>, HTML is a built-in data type. HTML templates are first-class values that may be computed and stored in variables. An HTML template may contain named gaps that are placeholders for other HTML templates or for text strings. Such gaps may at runtime be plugged with concrete values. Since those values may themselves contain further gaps, this is a highly dynamic mechanism for building documents.

A flow-sensitive type checker ensures that documents are used in a consistent manner: for instance, it is checked at compile-time that in every document being shown to the client, the input form fields in the document match the server code that receives the values. This is only possible because of the combination of the session based service model and the HTML template mechanism.

Furthermore, a unique program analysis ensures at compile time that only valid HTML 4.01 documents are ever constructed and sent to the clients at runtime. So far, no other Web service development system with a flexible dynamic document mechanism can achieve such a guarantee.

And finally, the system allows advanced client-side caching of dynamically generated HTML documents. Most Web services that dynamically generate documents have to effectively disable the browser cache resulting in significant performance losses compared to static Web pages. With the <bigwig> dynamic document model, HTML fragments can be cached in the browsers.

The original design of the dynamic document model is described in the paper A Type System for Dynamic Web Documents, the technique for verifying HTML validity of documents is explained in Static Validation of Dynamically Generated HTML, and the caching mechanism is presented in Language-Based Caching of Dynamically Generated HTML.

PowerForms

In many existing Web services, a significant amount of time and code is being spent on checking that the user input is valid, for instance that certain input fields must contain numbers only, that one field is required to be filled out if some other field has a specific value, etc. If the input is invalid, error messages must be shown, and the current page must be shown again instead of continuing the service. For convenience to the user, the validation usually takes place on the browser using JavaScript, but an extra check must be made on the server.

The <bigwig> solution is a tiny declarative domain-specific sub-language called PowerForms. Regular expressions may be defined and associated with form input fields. These regular expressions are then compiled to efficient JavaScript running in the browsers and C code performing double-checks on the servers. Sophisticated interdependencies of input fields can also be expressed using an additional layer of boolean logic. The JavaScript code is carefully written to exploit only the subset of JavaScript that is known to run on all (reasonably new) browsers. The result is that the input fields are validated incrementally on the client-side, an HTML page is only allowed to be submitted when all its input fields comply with their associated regular expressions, and the service code is no longer cluttered with large amounts of input validation code.

PowerForms is described in more detail in the paper PowerForms: Declarative Client-side Form Field Validation.

Database Support

The familiar struct and array data structures are replaced with tuples and relations which allow for a simple construction of small relational databases. These are efficiently implemented and should be sufficient for databases no larger than a few MBs (of which there are quite a lot). A relation may be declared to be external, which will automatically handle the connection to some external server. An external relation is accessed with (a subset of) the syntax for internal relations, which is then translated into SQL.

Security

A standard service executes with hardly any security. Higher levels of security, implemented through the SSL and HTTP Authentication mechanisms, may be requested, either or the entire service or for individual sessions or interactions.

Macro Mechanism

For gluing together the various sub-languages of <bigwig>, a general syntax-level macro mechanism is provided. This also allows <bigwig> programmers to extend the language by adding new productions to its grammar. All nonterminals are potential arguments and result types for such macros that, unlike C macros, are soundly implemented with full alpha-conversions. Also, error messages remain sensible, since they are threaded back through macro expansion. This allows the definition of "very domain-specific" languages that contain specialized constructions for building chat rooms, shopping centers, etc.

The macro mechanism is described in the paper Growing Languages with Metamorphic Syntax Macros.

Availability

The complete source code for the <bigwig> compiler and runtime system is available under the GNU Public License. It runs on Linux/Solaris systems with the Apache Web server. (There is currently no Windows/IIS support.)

(Previous versions of <bigwig> contained an advanced concurrency control mechanism where the concurrent behavior of the session processes could be controlled by synthesizing finite-state controller automata from control logic specifications. To simplify installation and maintainance, this has been replaced by a simpler locking mechanism in version 2.0.)

bigwig@brics.dk
Last updated: September 13, 2001