A proposal for Webapps

Example

The following is an example of a webapp with a graphical user interface. The syntax is hypothetical, inspired by several computer languages, and only serves as an example of what a webapp might look like.

This webapp plays tic-tac-toe, the little game of noughts and crosses on a 3×3 square. The first part of the code contains the program logic, which is essentially a loop that waits for a move by the user (i.e., selecting one of the nine squares) and responds with a move by the program, until either side has won or there are no more moves. This part is independent of the particular user interface: it is written in terms of commands on input (abstract "messages" or "events" coming from the user interface manager) and instructions on output (other messages, destined for the user interface manager).

require Webapp

# Declare the commands the program accepts:
declare_commands [
  ['set', INTEGER],
  ['reset'] ]

def make_move(board)
  # If the game isn't over, make an intelligent move...
  # [...code omitted...]
end

board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
ready? = false

while c = get_command
  if c[0] == 'reset'
    board = ['.', '.', '.', '.', '.', '.', '.', '.', '.']
  else if board[c[1]] == '.'
    board[c[1]] = 'x'
    make_move(board)
  end
  board.each {|s| puts s}
  puts "\n"
end

The code above simply reads a command and outputs the result as text. Strictly speaking, a webapps user agent needs no more than this to allow a user to interact with the program. But such interaction won't be pretty: it will be a simple dialog, in which the user types or selects a command and the program responds with a line of crosses and noughts. The interface won't look like a 3×3 square at all, because the user agent doesn't know it is supposed to look like that…

On the other hand, it will work on more or less any device that allows the user to input numbers and that shows (or speaks or otherwise outputs) text.

To make the game more enjoyable, the author should provide one or more user interfaces along with the program. Here is a graphical one, that shows 3 rows of 3 buttons. (For brevity's sake, we only show two of the nine buttons.)

# Parse the message from the program and
# send each button its part:
/(.)(.)(.)(.)(.)(.)(.)(.)(.)/:
  b1 $1; b2 $2; b3 $3
  b4 $4; b5 $5; b6 $6
  b7 $7; b8 $8; b9 $9.

window main
  title = "Tic Tac Toe"

button b1 (main)
  value = "."
  location = "0 0 20 20"
  /x/: value = "X".
  /o/: value = "O".
  ACTIVATE: print "set 1\n".

# ... 7 similar buttons omitted...

button b9 (main)
  value = "."
  location = "40 40 20 20"
  /x/: value = "X".
  /o/: value = "O".
  ACTIVATE: print "set 9\n".

button reset (main)
  value = "Clear"
  location = "0 60 60 20"
  ACTIVATE: print "reset\n".

The GUI is defined by a number of objects of various types (window, button) each with various attributes (value, title, location) and actions. Actions are either in response to messages (the /…/ contain regular expressions to match messages) or to user events (ACTIVATE is a predefined event for a button).

This is just one of the possible user interfaces. The author can provide others for the user to select from, or the user can make his own.

Requirements

Webapps are a means to publish procedural knowledge, just as HTML (and several other formats, such as SMIL, RDF, SVG, etc.) is a means to publish declarative knowledge. One can do that with Java or with traditional programs that have to be compiled and installed, but there is a place on the Web for a format that does to programs what HTML did to documents: extremely easy to write, quick to download and sufficient for 80% of the cases.

1. No installation needed. Like HTML pages, webapps can be stored either locally or on a server and can in both cases be started with something as simple as a mouse click. They should download quickly and run without further installation (except as needed for possibly dangerous or privacy-invasive operations, see under Safe below).

2. One webapp = one URI. A single URL is enough to address a webapp, so that it is possible to link a webapp from an HTML page, or include it as an HTML <object>. The webapp may in turn contain multiple resources, such as program modules or UI definitions, which may have their own URLs as well (just like an HTML file may have images and style sheets). Some compound format, such as TAR, ZIP or JAR, may be needed.

3. Easy to write. This means the language(s) they are written in should be fairly high-level, with good support for strings, implicit data-typing with no (or optional) type declarations, using a familiar programming model and syntax, probably Algol-like, maybe with optional OOP facilities. For the (G)UI, a declarative pattern-action language, like CSS, is probably best. There should also be high-level APIs to libraries for reading/writing (or GET/PUT) files on the network.

4. Accessible. Probably the best way to ensure that, is to make the user interface optional, similar to the way CSS is optional for HTML. A user can read a correctly written HTML document with his own UI, ignoring the style sheets provided by the author; likewise, a user should be able to use a webapp without any of the UIs provided by the author. In most cases, the default UI that the user agent offers will be “functional,” rather than optimal and when the author has provided a UI for the particular platform of the the user, the user will want to use that instead. Nevertheless, the possibility to run without the UI is important, not also for accessibility, but also for being able to connect (“pipe”) webapps together.

5. Device-independent. Device-independence is partly achieved with the same means as accessibility, i.e., abstracting the application from its UI, but also it requires careful thought when designing the standard libraries (built-in functions) of the webapps language(s). Not all functions can be provided by all platforms, but the APIs can be designed in such a way that it is easier to program a fallback, than to let the program crash.

6. Safe. Since a webapp can be opened with the same ease as a Web page, they should be as safe as well. They should run inside some sort of “sand box”, with no access to the user's file system or other system resources, unless the user explicitly grants access. A system of permissions is probably needed, so the the user can grant access to some resources, but not others: access to persistent storage, read/write access to one directory or to a whole file system, access to system information (CPU type, OS type, etc.) or personal information, limits on CPU and memory usage, etc.

7. Privacy. Webapps may send information to remote servers, just like Web forms, and should thus declare what those servers do with the information. If the webapp is downloaded by HTTP, a normal P3P header in the HTTP is probably enough. Otherwise the webapp itself should link to a P3P policy (see metadata below.)

8. Persistent storage. Despite not having access to the user's file system, a webapp should be able to store data on the user's machine, so that it can resume a previous session after being restarted. This persistent storage is a virtual file system, that is only available to a particular webapp, or to the group of webapps sharing some cryptographic key. The user can grant each webapp a certain amount of persistent storage, including none at all.

9. Cooperating webapps. Multiple webapps executing in parallel should be able to communicate. The persistent storage mentioned above may include functions for file locks or semaphores for that purpose.

10. Network operations. A webapp can access the network (e.g., to act as a front end for a remote database or to act as a chat program). It needs a socket API (BSD sockets) and probably also a higher-level API, to GET/PUT from/to URIs. Maybe the latter should include WEBDAV and SOAP. Which servers a particular webapp can access is a function of some trust settings in the user agent.

11. Source code. To help spread the technology and to encourage re-use (rather than re-invention) of algorithms, it should be possible for a user to do a “View source” on a webapp, in the same way as on an HTML page. This also helps improve webapps, since interested users can provide patches to the author.

12. Extensible. The first version of the webapps language(s) won't be perfect and it good to calculate with updates. As computers become more powerful, new built-in functions can be added as well. New UI paradigms may also emerge, necessitating extensions to the UI definition language (or development of a completely new UI language).

13. Multiple languages. Maybe not in the first version, but in a later version, it would be useful to allow different programming languages, since not all programmers like the same language. E.g., it might be possible eventually to allow webapps to be written in Java as well, so complex programs can be written more easily.

14. Integration with the Web. Integration is dependent on the facilities provided by the user's platform, but if the platform has both a user agent for webapps and a browser, it should be possible to cut and paste text between them, click on a link to a webapp in the browser, display the webapp in-line in the browser, etc. One of the built-in functions of the webapps language should be a function that directs a browser (if present) to open an HTML page or some URL. (The browser and the webapps user agent may be single program, but need not be. Some platforms may offer only one of the two.)

15. Not for high-speed graphics. A webapp cannot directly access the graphics hardware or any input devices (joystick, mouse, keyboard, etc.), because of requirement for device-independence and accessibility. It has to communicate with the UI manager of the user agent via a serialized stream of commands or events and thus is less suitable for programs such as shoot-em-up games or movie players. Since such programs aren't very device-independent to begin with (they require graphics output), that doesn't seem to be a big drawback. Of course, a webapp should be able to demand its environment to play a movie on its behalf, e.g., by sending the URL of the movie to the platform's browser.

16. Skins. Each UI provided with a webapp is, of course, a “skin” for it, but what is meant here is the type of skin consisting of irregularly shaped, colorful images, that make applications such as sound and video players so hard to use (but beautiful to look at). Webapps should be able to have controls that are specially drawn for that application, rather than taken from the standard library of GUI widgets. Ideally, these graphics should be scalable, so they adapt to the user's default font size, either because they are made with a scalable image format, such as SVG, or because the author provided them in various sizes. Probably each kind of GUI widget (window, button, label, etc.) should allow its default look to be overridden by one or more images, while keeping its other characteristics, in particular accessibility features, such as keyboard access.

17. Graphics output. If the UI is a GUI, it should be able to draw graphs and display images (possibly remote images). This probably means that one of the GUI widgets should be a 2D canvas widget, that can draw on itself.

18. Metadata and icons. A Webapp should include somewhere in its package of program modules and UIs things like version number, author, feedback address, digital signatures, P3P policies and also one or more icons, that can be used to represent the webapp in a list of bookmarks or in a directory of downloaded webapps.

19. Documentation and manuals. Other things in a webapp package could be documentation (for developers) and manuals (for users). The manuals (a.k.a. help files) could be in HTML and cross-linked to the UI, so that users can ask for help and the user agent can display the relevant manual page. Or the user agent can hand the manual page to the platform's help viewer or to a browser.

20. Localization. When the webapp is downloaded over HTTP, language negotiation can be used to get the version of the UI (and of any manuals, icons or other resources) in the user's preferrred language. The webapp itself can also be available in several versions, but that should be less common, since users typically interact with it through (one of) the webapp's UI(s).

Implementation ideas

Webapps are a new technology, although, of course, it has many inspirations: so-called “thin clients”, Java applets, “DHTML” (HTML pages with JavaScript), and more recently: Watson, Sherlock, Konfabulator (all three on the Mac) and Karamba (KDE). The hard part is to know what can and should be reused from other technologies and what should be developed independently.