We’ve seen a lot of scripting in this book. Too much? I admit there’s a tendency to regard some of the cobbled-together solutions I’ve shown as “just a bunch of scripts.” It’s true that to integrate the range of components needed to create useful groupware, you’re going to have to write scripts. But in Part IV I show that precisely because these scripts use the same methods and protocols as do the core Internet services, they can be not only flexible but also very resilient. The monitoring tool we build in Chapter 14, for example, sees all HTTP services equally, whether they’re provided by homegrown scripts or by open-source or commercial applications. In my experience, any nontrivial web site is always built using a mixture of these components. The commercial ones aren’t necessarily more (or less) intrinsically reliable than the homegrown ones. No matter what, it’s an administrative chore to make sure all the parts are working together smoothly. But when the parts are Internet-style components, that chore is automatable—and rather easily too.

Scripted HTTP services are so useful that, in Chapter 15, I explore the idea of deploying them locally, on users’ workstations, where they can deliver applications into local or remote browsers and be components used by local or remote processes. This peer-to-peer approach to web computing can attack a range of problems typical of groupware, including support for offline users and data replication.