From Web Content to Applications
Ashok Malhotra, Larry Masinter, T.V. Raman
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.
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.
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.
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.