In this extended example, we will go walk the development of a web-enabled service for source code control and build tracking. This example is taken from the system and facilities used in the development of RScheme itself.
The first step in building a web-enabled service is to understand the domain. This means understanding what the conceptual objects are, what their relationships are, and what procedures or operations are to be web-enabled.
For this example application, the domain is that of source code control and build tracking. The objects are things like virtual filesystems, source files, filesystem snapshots, groups, users, change requests, and builds.
The are several kinds of relationships among these objects; filesystems contain files, files are owned by groups and users, files changes are motivated by change requests, etc.
Builds use the source from filesystems at a particular snapshots.
The next step is to design the web space. This involves understanding how the conceptual objects map onto web pages, how their relationships map onto links among those pages, and how the operations and procedures are appropriately represented using forms.
For this application, I chose a fairly direct mapping of application objects to web pages; each object is represented by a single page in the web space, with top-level web space links encoding type information.
For example, the page that describes change request 803 has the path /cr/803.
Since some of the objects being mapped are files, we get what appears to be a virtual filesystem of metadata published on the web. For example, the page describing the file /handc/configure.in in the filesystem rs-0.7 is located at /fs/rs-0.7/file/handc/configure.in. It isn't necessary to use file names in this case -- the equivalent of inode numbers could be used as well -- but using the file names corresponds more closely with the an intuition about the shape of the web space.