XForms/Versioning Form Data With WebDAV and Subversion

Motivation

Users frequently want multi-versioned forms. This means that they not only want to keep prior versions of a form's instance data but they also want to:

• be able to view prior versions
• compare the current version with a prior version
• see who changed what fields on a form an when
• revert to a prior version

This problem frequently occurs in complex computer systems that have configuration files. Something stops working but people don't notice it till later. There is no information about what the prior versions of configuration file looked like so the entire systems must be restored from backups. Many of these problems could be avoided by automatically reverting to the prior version of a configuration file.

Background

With the XForms standard we are given the <submission> element and a small list of HTTP operators (GET, PUT, POST) to use and an action that can be any URL. If we want to allow users to save form data to a version-control system or to see prior versions of a form we have to translate these operations into something that a web server will recognize as operations on a version-control database.

Subversion is an open-source version control system with a client/server architecture (as opposed to a file-based architecture typical of other version controls systems).

Unlike older file-based version control systems, Subversion uses a transaction server model similar those used for reliable banking transactions. This makes subversion very reliable and allows you to check-in (or commit) groups of files that should be checked in together. They will either all succeed or all fail but the version controls system is guaranteed to always be in a consistent state.

Subversion also conforms (where it can) to the WebDAV WebDAV stands for Web Distributed Authoring and Versioning specification. The standard web HTTP protocol supports just a few operations such as get, put and post. WebDAV extends these simple operations to include operations we might expect on a file system such as delete, move and copy. Since WebDAV is more about file operations and Subversion is more centered on transactions, sometimes there is not an exact fit between the two.

Subversion has two principal concepts:

• update - gets the latest version of your code from the server.
• commit - take all the files you have changed from your local file system and save the changes through a transaction on the server.

To allow forms data to save to subversion we need to make a submission element do a commit. This is not necessarily hard but we want to be clear how the systems are different.

Subversion, WebDAV

Subversion is a version control database. At its core, it does not include an independent access control system. Because it is usually installed as part of a web server it usually uses the access control system of the web server it runs on. Apache also supports the WebDAV HTTP extensions which allow complex operations beyond the basic HTTP get, put and post. One of the best ways to get XForms to be persistent is to configure Apache to use WebDAV with

Autoversioning and Apache

To configure autoversioning with Apache2 server you must modify the configuration file. This file should be configured to support your XForms work.

WARNING!: Any time you allow public access to write to your server you are dealing with security issues. You should always consider ALL of the security implications before you make ANY changes to a web servers configuration file. Make sure that security professional in your organization review any systems that have public web access.

You will want to have an Apache configuration similar to the following somewhat half-XMLish format:

 <Location /repos>
    DAV svn
    SVNPath /var/svnrepos
    SVNAutoversioning on
    <LimitExcept GET PUT POST PROPFIND OPTIONS REPORT>
        Require valid-user
    </LimitExcept>
 </Location>

See also the well-written chapter of the Subversion Red Book or the respective excellent Gentoo 's Apache-SVN-WebDAV-HOWTO section for detailed configuration help with examples.

Converting HTTP PUT into Subversion Submit

The last step is to convert HTTP PUT into a subversion COMMIT. This can be accomplished using a program such as Jetty.

(We will post a sample program soon).

ViewCV and ReST

You can also start to add tools to Apache and Subversion to get colorful output that shows the differences between prior files. One option is to add the ViewVC (View Version Control) system to your Apache server. ViewVC allows you to see version history can compare prior versions just by addeing parameters to the URL. This method of using the URL to pass parameters to a server program is frequently called a REST interface. Almost all REST interfaces are easy to interface with XForms <submission> since XForms can encode the submission instances directly onto the URL.

Subversion REST URL interface

Subversion allows you to access a resource's version history by adding an additional path to the URL. See [1]

For example if your file name was

http://www.example.com/my-repository/myfile.xml

If you wanted to get version 47 of a file it might be:

http://www.example.com/my-repository/!svn/ver/47/myfile.xml

Debugging Tips

The Subversion FAQ suggests you run the Wireshark packet sniffer and look at the data in the HTTP messages. You can also use the Charles Web debugging proxy which also has a nice FireFox plug-in. Just make sure you know how to disable the proxy by going to the Firefox Tools/Options/General/Connection Settings and click the Direction Connection to the Internet. If you do not your web browser will no longer function when Charles shuts down.

References

DRAFT of webDAV usage with subversion

Subversion source code stored in Subversion