about the <bigwig> project |
the runtime system |
dynamic documents |
database support |
macro mechanism |
<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,
an Apache Web server module. <bigwig> is a descendant of the Mawl
project but is a completely new design and implementation with vastly
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.
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.)
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
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.
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
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
browsers and C code performing double-checks on the
servers. Sophisticated interdependencies of input fields can also be
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.
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.
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.
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.
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.)