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.
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.
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.
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.
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.
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.
|
