Example applications of the two-way web

This is a grab bag of ideas I have had myself or that have been suggested by others. Most things here are eminently doable; whether all are desirable or anything but "nifty" is another matter. Further ideas are most welcome. It seems that everyone I talk to adds one more idea or twist to the set already here; this convinces me that there is some utility in this.

No doubt there are technical issues that will become visible when demos of these features are implemented.

Obvious / straightforward

Chat and other group communication applications

A lightweight chat server supporting a single chat room and not many bells and whistles can be written in less than 50 lines of JavaScript and a little HTML. I know this, because I have written one. The client is about twice as big, but still written only in JavaScript and HTML, and uses no Opera-specific features.

The client sends requests--signifying message posts or queries for new messages--to the server in the form of normal HTTP requests. The requests cause the invocation of script functions in a page loaded on the web server (ie, inside Opera). The scripts compute their answers and return them as XML, which is then parsed by the client and displayed.

Interactive multi-player games

Users who are not co-located but who wish to play games together can use programs written in JavaScript/DOM and communicating by HTTP to do so. Simple examples are board games like Backgammon and Othello. Most games that do not require rapid real-time response should be straightforward (especially in combination with OGP).

Sharing of information in a group of Opera instances

Opera users may wish to publish some of the information available in their Opera instances. The obvious example is bookmarks: say a user marks a bookmark as public. Then anyone accessing the bookmarks service on that user's computer will see the bookmark.

A bookmarks service is easily implemented; I have done so. Bookmarks are exported as XML. Bookmark aggregation services could perhaps be built on top of this (and gives us a basic recommender system), but another application is for the user to be able to access her bookmarks while at another computer.

In a similar way, it may be desirable to export some contacts or notes, and if Opera were to have a calendar/appointments function, to export appointments and use an information aggregator (see below) to create a calendar for a group.

Lightweight dynamic queries, for small groups

I believe many users have occasional simple needs for a web server that can interact with its environment in trivial ways. For example, one may wish to run a simple web site for a small organization, accepting form mail from the site for queries and membership registrations.

It is easy to support this in Opera. There are two ways. One could support traditional CGI scripts. Or one could allow the scripting language to interact with its environment in controlled ways. For example, the way Opera's web server works now, a script receives the data passed by a form submission as a string. The script ought to be able to use M2 to send these data on to a third party, or to save it as a mail message in M2's inbox.

It is also unproblematic for server-side scripts in Opera to access databases or the file system, in most cases, and these facilities should exist.

(I think we should support CGI also, because one should never throw away working, reusable code, and there are many scripts out there.)

Remote control of Opera

Since a web server is first of all a server responding to commands, it can be made to invoke internal functionality, thus one can control Opera from afar.

There are probably limited uses for this, but one I have come up with is remote control of Opera during an OperaShow presentation. Opera on a laptop is connected to the Internet and is running the presentation; the webserver is active. The presenter is standing elsewhere in the room with her phone running Opera (or another browser, really). When she wishes to move to the next slide, she can press a button on the web interface on her phone; this submits a request to the other Opera, which will page down as it would normally do and show the next slide.

Information aggregation, filtering, abstraction, and re-presentation

Some information sources become more valuable if their data can be presented in a "richer" format. For example, a person who reads many blogs may find it easier to aggregate these into a single web page and read that than to switch between many pages. The same is probably true for RSS feeds, and for news services generally.

A web browser can fairly easily implement a meta-search facility that submits a query to multiple engines and then creates a summary of the result. (Actually it cannot, because of the too-restrictive JavaScript security model, but that is fixable.) A web server can then provide access to these summarized results.

Data that are expensive to gather (either computationally or because a lot of data must be transferred for presentation purposes) can similarly be abstracted on a server and re-presented in a format more fitting for small devices--for example, NSB has a site with information about train delays that is slow and transfers quite a bit of data. An Opera server can access this site every few minutes; a client on a phone can access the Opera server and be served a summary.

The key point is that every Opera user can create her own summaries and serve them in a convenient form.

Personal information manager

If Opera is becoming something more like a personal information manager every day, then Opera instances should be able to exchange and synchronize information. This is easily done if one of the Opera instances has an HTTP server: it can both serve the current state of the system and accept updates.

Speculative / advanced

Programmable proxy

Right now it is a little unclear what advantage we could derive from having a proxy. Some ideas include ad filtering, anonymization, load balancing, and group-speaks-with-one-voice services. But it should be clear that if we do have a proxy, it needs to be programmable just like other services are: any request can be served from a file, or from a script, or by an external program.

A novel application for a network of proxies is beating the automatic Slashdot ban on too-frequently updating RSS readers. :-P

Peer-to-peer file sharing

A peer-to-peer file system consists of three mechanisms: for indexing, for download, and for upload. The index maps query terms to URLs where files (or fragments thereof) may be found. The index must typically be distributed and replicated, and index searches are forwarded through the network in various manners.

Once a location for an indexed item has been found, HTTP can be used to download the file.

Files are also replicated, either eagerly or lazily. In eager replication one needs to upload files. An upload is just a download that sends a URL to the target agent and asks it to download it.

It seems to me that by adding very simple functionality to Opera and to the environment component of the scripting system, one can implement practical file sharing entirely with JavaScript, XML, and Opera.

Distributed computation (a la SETI@home)

Some distributed computation is very easily implemented. One computer at a known name acts as a coordinator. Other computers connect to it to make themselves available in the work pool (this is just a GET to a server on the coordinator). When there is work to be done, the coordinator contacts a worker (using a GET on the worker's web server), passing it a URL that names the work to be done (a simple HTML page). The worker loads this page, runs it locally (in the security domain of the coordinator, so there is no security issue), and when the computation is done the page submits the result to the coordinator with another GET.

See the mandelbrot program in the examples directory for a simple application of this.

(It is an issue that JavaScript is not quite as speedy as C or Java, but we should see that as a challenge to be taken on, not as an impediment.)

Linda is a technology for simple distributed and parallel computatation, proposed by David Gelernter [1]. The idea is that there is a "tuple space" that contains tuples of data, these are data to be worked on and the results of computations. Agents interact with the tuple space by reading and writing tuples, some agents are pure workers and others are coordinators. A tuple space should be easily implementable with our web server technology; phrasing the above example in terms of a tuple space, work to be done are simple URLs and work accomplished are pairs consisting of the URL and the result of the computation.

Web-Mail service

Suppose you have a home office with several computers that you use. (I do.) If you are like me, you will end up downloading your mail onto multiple computers, because it is desirable to be able to read mail everywhere. This is not ideal. We can do better.

A mail message in Opera is just an XML structure. It would be simple for a web server to get a mail message from M2's mailbox and reformat it as HTML, thus creating a simple web-mail client.

Citations

[1] It looks like http://c2.com/cgi/wiki?TupleSpace is a good place to start.