Servers / Clients/ Centralization. The center of nowhere in particular
Mitch Kapor blogs eloquently on the design issues that come with building a workgroup product for an organization. While the OSAF's Chandler is a P2P-based product at heart, and Mitch a decentralizer at heart, when it comes to big groups, servers become sort of important.
But is a server centralization? Especially if local repositories on the users' PCs are full of almost all the same information? I asked a purposefully dumb question of David Isenberg about this at Supernova last December, about his the end of the middle presentation, which show lots of clients but no servers (literally, pictures of PCs at the edge of the network — not the graphic on the linked page, but in his slides). His response, which I don't think comes through adequately in the presentation, is that a server is just another client — and I'd add, it's a client with an institutional memory.
This is always an interesting discussion. I've advocated on both ends of the spectrum. When the Web emerged, the web application server solved enormous issues for end-users and organizations. It's server-based quasi-centralized (yet still distributed) model was enormously cost effective and convenient for end-users. But it also lacked some of the richness that end-user applicaitons require (media, ui fidelity, real-time aspects, using the local desktop), and so we've seen the advent of 'rich clients' that move a greater amount of processing to desktops. But even in this newer (rich Internet apps) model it's very much a cooperative relationship and balance between edge clients and middleware.
Just like in matters of religion and politics, I don't think there's one answer — varying conditions inside corporations, device capabilitieis, network conditions, security infrastructure (firewalls), bandwidth, etc. all drive different architectures for application distribution and communications.
[Jeremy Allaire's Radio]