When you build web-based groupware applications, you’re also creating componentized, scriptable services. In Chapter 10, for example, we saw how a servlet-based group calendar implicitly supports import and export APIs, just because a web-client script can issue the same URLs that browsers do when they read and write calendar data. Servlets, like conventional CGI applications, can be coupled together in a kind of web version of the Unix pipeline. The same servlet that provided web APIs to import and export scripts also consumed a web API provided by a “todo server,” using its services to inject todo data into calendar displays.

When web applications are used both interactively and programmatically, it can be helpful to structure their outputs for the convenience not only of browsers, but also of scripts. We saw a simple example of this idea in Chapter 10, when we altered the calendar’s HTML output in a way that made no difference to browsers but that simplified script-based parsing of that output. In Chapter 14, we saw how to take this idea to the next level, using XML-RPC to define well-structured request/response protocols based on HTTP.

Directory services are another kind of component used by groupware applications. LDAP has emerged as the consensus standard not only in the Internet realm but on the LAN. In Chapter 11 we explored a transitional strategy that creates a common interface to a simple text-file-based directory, to the Windows NT domain database, and to LDAP. Built with Perl, these three directory modules demonstrate another way to componentize services used by groupware applications. In this case, the technique helps isolate applications from a directory services infrastructure that is in transition to LDAP but not yet fully standardized on it.