Nick Hill wrote:
I envisage many wikipedia servers around the world, supported by private individuals, companies and universities. Much like the system of mirror FTP and mirror web sites. All these servers are updated in real time from the core wikipedia server. From the user's perspective, all are equivalent. Each of these servers can do everything the current wikipedia server can do except for accepting update submissions. Updates from users are accepted only by the core wiki server.
Organizationally, this would be a nightmare. Having a central server farm really eases everything, because the volunteer admins can be given root passwords, etc., and the ability to make changes on all the servers very quickly. It's not easy to get that kind of access if we are co-ordinating across many servers around the world.
Co-ordinating across many servers around the world *is* a solution we can ponder *if* it appears to be absolutely necessary for some reason. But it strikes me as unlikely for this to be the case.
Reasons for such an architecture:
- Growth of bandwidth useage may put financial pressure on Wikipedia.
Growth may follow a non-linear growth curve.
With the continued fall in bandwidth costs, this is very unlikely to exceed my capacity to support Wikipedia in the short run. *Bandwidth* per se, is not a major issue.
- The cost of implementing one very fast, reliable, redundant machine is
more than the cost of farming out work to many quite fast, unreliable systems none of which are mission critical. Especially true where there are people willing to donate part of their hard drive, CPU and net connection (or even an entire system) to a good cause such as wikipedia. (Overall system reliability can be guaranteed by using DNS tricks to ensure users and queries are only directed to working machines).
This is easy to say, but harder to implement well. I don't know of any really successful implementations of the kind you are discussing.
--Jimbo