Every communication book I ever saw had a page of topology
diagrams that showed the StarNetwork as a starting point
from which to generalize to truly interesting configurations.
My peers and I have always looked down our noses at anything
labeled client-server without actually realizing that the
issue has nothing much to do with topology.

The real issue is division of responsibility in
the presence of two masters.  Consider business:
The business put in the first computer and expected
it to serve business needs.  These were largely related to enterprise
integrity.  Now forward-looking businesses provide employees
with personal computers.  These computers serve their users
by increasing personal productivity.  It is important to 
understand this fine distinction.  The client computer serves
the user who serves the business.  The client computer does
not serve the business directly.  With this distinction
clearly in mind it becomes much easier to allocate 
responsibilities and design protocols in client-server 
systems.

JohnTibbits first made this clear to me.  -- WardCunningham

-------------
''(Can someone generalize this argument for the unique client-server properties of the world wide web?)''

I always considered "client/server" architecture to be FatClient''''''s with at least network/remote RDBMS access via queries instead of file-based table access (such as "LAN databases" that came before). Most of the business logic happend on the client, but "large-scale" processing was done on a database server using either queries or StoredProcedures. This differs from web-apps, which has most of the business logic on the server and uses web browsers. They had rich GUI's, but difficult deployability. --top