Fifteen years after its inception, the web is still one-way to a large extent. It is becoming affordable to host web sites with web hotels or with ISPs, yet it is not straightforward or free to do it, and most Internet users do not have a personal web site viewable by other people [1]. When they do, these sites are updated with difficulty and are generally completely static. The technology to make them dynamic is also difficult to master--usually requiring the use of Perl, Java, Visual Basic, or sundry shell languages.
It is time to fix this, and Opera is in a position to fix it. I propose to add a web server to Opera (for static and dynamic content). Obviously one could add a server application to the system instead of adding a web server to Opera, but the reason for doing it inside Opera is that Opera already has a large following, and many of our users will be tempted to try the Web server when it is already there and easily accessible. If we make it easy and useful, it will be used.
The web first of all needs a simple solution for serving pages from home computers. Apple has gone some way in this direction with its "Personal web sharing" technology, built on Apache. On a machine running MacOS X, simply start personal web sharing and point Apache to the right directory, and you're set. There is a GUI for this, and it is easy to do.
Apple's solution neglects the fact that most users do not in fact have their own domain names and instead use DHCP to get internet addresses. It also does not do much for most people, since most people run Windows, not MacOS X.
It is my opinion that Opera should rectify this problem in the Windows world (and on desktops in general). We are in a position to do so in a simple way, and we should start by following Apple's example and make it simple, above all. Starting our web server is easy: open the preferences panel, click "turn on web sharing", fill in the name of the root directory on the local system from which files should be served, and you're done. The computer now has an HTTP server, serving the owner's personal web site.
But we must also solve the problem of finding these sites. Opera, the company, should provide a service whereby an Opera user can register (somehow, and for very little or no money) and will receive a host name for himself in the opera.com domain. Say I am lucky and I get to use the name 'lth.users.opera.com' for my computer. When I start my web-server enabled copy of Opera, it will contact Opera's name servers and tell them that right now, lth.opera.com has address 82.124.12.73. (This is just dynamic DNS; others do it too.) Anyone wanting to view my web site looks for it on http://lth.users.opera.com. If my computer is up, the site is served. (If it is down -- too bad).
A different possible solution is to forward http://users.opera.com/lth to my site, but it is less elegant and will suddenly expose the temporary IP number to the user agent. To fix this, users.opera.com would have to behave as a proxy, and though we are in the proxy business a little bit, I don't know if we want to take this on for the desktop market as well.
The web is divided into servers, which serve content, and clients, which access content and display it. (There are also proxies.) Servers also process complex requests for information, for example turning a web query into a database query and formatting the query results into static HTML for display. As suggested above, it is easy to add a server for static content to a client, turning it into a little bit of a two-way street. The challenge is to make it nearly as easy to serve dynamic content.
The technologies already available to us--XML, HTML, DOM, and ECMAScript--are more than powerful enough to implement much of the desired dynamic functionality. We need to provide a few hooks to access the browser's internals (like M2) and environment (like the file system), but this is not hard and can certainly be handled in a safe manner. Thus dynamic functionality is within reach.
And this dynamic functionality has nontraditional applications: it can be used to implement services that filter or aggregate information from yet other services, and present them in ways more desirable to new clients. Thus it is becoming clear that clients and servers are merging to some extent, and that "web browser" and "web server" are names for functionality, not for programs. The program might be called a "web agent", though that name is certainly used for other things as well.
A related point is that a typical instance of Opera contains useful information: organized sets of bookmarks, notes pertaining to web pages, and personal information like contact lists. We could even see an expanded version of Opera containing PIM-type information like appointment calendars. To some extent it is desirable to publish this information, and what better tools than HTTP and XML for making it available? A web server in Opera should--at the user's request--serve a subset of the information that Opera has stored.
If Opera is storing information, exporting it, and used for reading it, it should also be able to import it. Implementing that would be nearly trivial, and would provide a simple synchronization facility, perhaps.