Much has been written about Web 2.0. It’s nice to see such a protocol being revitalized—the wisdom of the Web’s simple elegance recognized. But much of the WS-* furor seems to have missed the point of Tim Berners-Lee’s beautiful GET, POST, PUT and embedded links. When I see serious documents referring to a processor as a provider of services—and honestly appearing to believe that clock ticks come individually wrapped in XML—I worry. Certainly, many of these people seem to believe that XML parsers are small’’ and should be ubiquitous. In their haste to adapt pre-web systems and ways of working to the new buzzwords, they neglect the management and overhead costs of all these layers of serialization and redirection.

I’ve been pleased to see Tim Bray and others reminding us all that WS- has little to do with what makes the Web great. But it’s not enough. Some people are proceeding to build reasonable Web Services and Service-Oriented Architectures… but in general, they’re not doing it with the WS- standards. They’re doing it with simple HTTP and XHTML, often with REST-based systems. SOAP is nowhere in sight.

Therefore, I call for advancement by means of a return to still simpler, more basic good than the Web: Gopher Services. This provides a much more natural, flexible means for representing traditional client-server applications in a SOA world. Gopher, for the young’ns in the audience, was a precursor to the web. A given site would provide a "gopher hole." Each node in a hole contains either an ordered list of links or a flat file. Some links go to nodes in other gopher holes. Like the web, links obscure the complicated protocol-level description of the link with a human-readable label. Unlike the web, there’s no place for readable URLs: humans only get the painted-on link names. Common practice was to use null or short-cycle links to provide structure and annotations within the lists. Go look at Quux for an example of how this works.

Because most links are local, links are separated from content, imperative links are clearly called out, and a client tends to interact with its "home gopher hole," this is a far more appropriate model for bringing Service Oriented Architectures to classical enterprise computing. Rather than jumping straight to a zillion tiny separate services, these organizations want a gradual shift. Hole-Oriented Architectures provides that middle ground. A hole provides services, but centralizes them. Client-server interactions fit in well. REST is out of the question, and you don’t have to pervert the Web to establish your client-server overlay network. You can just do C-S directly.

To achieve this renaissance, we need to revamp and improve Gopher. We need to do it Gopher what Ajax and Flash do to the Web, and finish what TurboGopher VR started back in the early 90s.