When you point a browser at a local instance of dhttp, you can pretend that you’re running a purely local application. It doesn’t matter whether you’re online or offline, and this offine capability is one of the unique strengths of the local-web-server technique. But dhttp really is an HTTP server, so if you’re connected to the office LAN or WAN, your colleagues can use your plug-in apps just the same way you do. In other words, a network of dhttp nodes is a peer-to-peer network.
This peer capability is so general that it takes a bit of getting used to. Suppose you and I each run an instance of dhttp, and we each maintain our own private database of contacts—mine on machine my-dhttp, and yours on machine your-dhttp. Table 15.2 shows the matrix of possibilities.
Table 15-2. Peer-Networking Matrix
|
Operation |
Browser |
URL |
|---|---|---|
|
I use my database. |
mine |
http://my-dhttp/sfa_home |
|
I use your database. |
mine |
http://your-dhttp/sfa_home |
|
You use your database. |
yours |
http://your-dhttp/sfa_home |
|
You use my database. |
yours |
http://my-dhttp/sfa_home |
Why wouldn’t we both simply use another machine, visible to both of us? We could, that’s another option. Nothing prevents you from deploying dhttp on a conventional shared server. For light-duty intranet applications, its single-threadedness isn’t a problem. And sometimes a shared data store makes the most sense.
Won’t the use of a central server cripple our ability to use local data and to work offline? Not necessarily. We’ll see shortly how to synchronize two or more dhttp nodes. But let’s assume that in this case, our two data sets are mostly nonoverlapping. You don’t need most of my records, and I don’t need most of yours, but once in a while we’d like to look at—or even add to—each other’s data sets. The symmetrical peer-to-peer model handles this situation without requiring replication of data to a shared server. Couple that with the ability to collect data while offline, and a peer-to-peer system can support some interesting scenarios. Suppose, for example, you detach your laptop from the network, visit a client, and collect some new contact information. On returning to the office, you dock your system, then go to lunch. A coworker in a satellite office elsewhere on the corporate WAN needs a phone number you just entered in your database. What was a portable offline data-collection device an hour ago is now a web server that provides the phone number on request.
Lotus Notes users will point out, rightly, that Notes handles this same scenario—though in a different way. A Notes user would undock, go to the meeting, enter data, return to the office, dock, and replicate with the central Notes server. Another user could then look it up directly on the central server or look it up locally after replicating with the server.
The dhttp model doesn’t preclude the Notes approach, but it does blur the boundary between services and applications. A dhttp plug-in is an interactive application that I can use on my own machine to enter and view data. But because it’s an HTTP-accessible service, it can be available to colleagues on the intranet, or even over the Internet, by way of their browsers. This kind of service can also work silently in the background, feeding information to other services. The desktop machine in my office can be as fully available—to an intranet or, with the right kind of firewall or VPN configuration, to the Internet—as is any nominal server machine.
Does it make sense to run services locally? Well, we live in interesting times. On the one hand, we’re in the midst of a return-to-the-mainframe movement—for good reason. PCs have gotten way too complex. A botched Windows registry all too often requires wiping the hard disk clean and reinstalling apps and data. Network computers didn’t take off as some people predicted, but the web model—disposable and interchangeable clients, install-free and upgrade-free software, network-based applications—is going strong. From this perspective, the last thing you’d want to do is add another moving part to your PC.
On the other hand, we do continue to want, have, and use PCs. Every month they grow more powerful. Although people lambaste Windows 95/98, the truth is that these systems are quite capable of delivering lightweight services as well as running interactive applications. NT and Linux are both gaining share on the desktop, and of course both these systems are capable servers. So the question arises: are these PCs only to be used to run Microsoft Office applications against file-server-based data and as terminals into which web-based applications are projected? If not—if we’re going to continue to have and use local data and apps along with all the server-based stuff—then we’ll want to figure out how local and remote computing can work together. A peer-to-peer system can help unite these two realms.