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:
1) 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.
2) 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