From Web Content to Applications

Ashok Malhotra, Larry Masinter, T.V. Raman

*Executive Summary*

Three major points

- How to capture application state
- Privacy/security of user data
- The "Web" is now more complex including Mobil devices, devices that are not always available, etc.

This seems a fundamental point but we need to extract the architectural issues from it.

*Introduction*

The Web was initially conceived as a worldwide system of hyperlinked documents with each document identified by a unique URI. The ability to introduce interactive behaviors into such online hypertexts, initially via fill-out forms, and later via event-handlers implemented via Turing-complete languages such as JavaScript, has enabled the creation of Web Applications.    Moreover, people realized that the Web could be used as a general mechanism for communicating
between application objects.  This is led to its use as a distributed object facility.  This builds on a long history of distributed client-server application technology, from terminal and screen sharing, Display Postscript, X protocol, and so forth.


The Architecture of the World Wide Web [AWWW] was written with a focus on the early document-centric vision of the web.  It needs to be updated to reflect the new emphasis on Web applications.  This document outlines some of the architectural issues that arise as we evolve to a Web of applications.



*From Documents to Applications*

When the Web was comprised of pure content (AKA web of documents), one could assert that every document had a unique URI (Universal Resource Identifier). Accessing a URI resulted in a specific /Representation/ being delivered over the wire — this accounted for variability in the delivered content, e.g., in response to language and device preferences. This mapping still held true as long as interactivity as permitted by fill-out forms was enabled via pure server-side processing of such requests --- the response to a given GET request that included form parameters could still be mapped to a single URI. But as we move toward a Web where interactivity is implemented client-side, with the consequent need to capture interaction state on the client, this somewhat simplified model breaks down.

An "application platform" for delivering a consistent user experience used to be supplied by the operating system. from Windows or Macintosh User Interface Guidelines etc. The Web Application Platform allows a new kind of interaction agent - the "Browser" (with or without added plugins) to create additional, different user experiences.  Perhaps more importantly, our notion of the “Web” has evolved to include Mobile, Wireless, Not-Always-Connected devices, connecting to Cloud Services. This change in context implies differing requirements.

In the case of Web applications, e.g., a Web-based email interface implemented in HTML+JavaScript, the URL (intentionally URL, not URI) does not address a single "document". This is because the state of the interface on the client at a given point is a function of the user interaction events that have been raised since the document was loaded. Said differently, in a Web Application, the /Document is the Interface/ — but this is not to be confused with /The Interface is a Document/. Notice that the state of the user interface at any given point in time can be serialized as a document, and it is frequently useful to do so — e.g., to capture a form in a given state for archival. The above leads to the following:

A URL for a Web Application is better thought of as a URL template that can generate a /
collection/ of documents.
   * Not every document in this /collection/ has a URI minted for it.
   * It is sometime advantageous to mint a URI for specific members of
     the above collection, e.g. to bookmark a given state, or to
     snapshot a given state for archival or legal purposes.
   * There is a fundamental requirement for capturing (and restoring)
     application state. In general this is very difficult but there are
     many idioms being developed for capturing state, some established,
     and others still evolving.

*Security and Privacy of User Data*

Policies are needed for the protection of user data that is transmitted to Web Apps. As we move towards Cloud Computing the user is likely to interact with a set of applications configured to run together in a manner that may be particular to him. In such complex collections of applications working together we are going to need policies on what user data can be shared with which application.

Several policy-based requirements for privacy and security involve informing or requesting confirmation from users about access to their private data or authorization to perform actions on behalf of the user. However, broad powers to affect the user experience - added to give UI designers flexibility - also interfere with enforcing consistent experience behavior.

*Persistence*

To capture application state we need to store client side data in a format richer than cookies. The requirements for this are not very well spelled out http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0303.html but nevertheless browser vendors are implementing such facilities and the WebApps WG is moving ahead with a feature called WebSimpleDatabase which provides for the efficient storage and retrieval of key-value pairs. There was some talk of providing full SQL functionality but that seems to be overkill.

There is also need for server-side storage in addition to database access to save and restore state as well as to share state across applications as well as to store configuration information.