On Sat, May 07, 2005 at 05:46:29PM +0000, Dori wrote:
On 5/7/05, David Gerard
<fun(a)thingy.apana.org.au> wrote:
Sj (2.718281828(a)gmail.com) [050508 00:53]:
The primary use I was thinking of was as a
failover option, even if
all normal servers blow up, go down, etc. But as long as such a system
is set up, however, why shouldn't it be available all the time? For
instance, if I were to design a game that involved regularly querying
WP content (and needed quick response times for it not to slow down
gameplay)... it would be much easier to do that through a central
static site than by setting up an incrementally-updating local mirror.
No need for us to rely on third parties like factindex to provide fast
static mirrors of Wikipedia content when that is what 90% of our
visitors want to see. (Or perhaps there is such a need? Depending on
said potential issues.)
You know, it occurs to me that serving the static version to anon visitors
by default might also be a nice way to implement that time-delay that
Jimbo
asked for when our [[2004 Indian Ocean earthquake]] article became so
popular.
Static would be good for not just for anons, but for all those that choose
it (I wouldn't force it on people as that'll increase the edit barrier even
if edit links point back to editable version). I don't have much faith in
time delay as fixing vandalisms would also be delayed.
That hints at one of my problems with the idea of using it as concurrent
service. I'll elaborate:
1. Maintaining up-to-date realtime mirroring would be a HUGE SUCKING
SOUND on bandwidth. This, it seems to me, is not an option.
2. Providing seamless integration between the two without roughly
realtime replication would make for very weird problems, as one site is
serving the "master" for a given set of articles and the other is
serving a several-edits-out-of-date version of the same articles.
Nothing comes immediately to mind as a way to make this work nicely.
3. Serving a delayed mirror to anons effectively bars anon edits in a
lot of unpleasant ways, as drawing in anonymous edits is largely
dependent on dilettantism. This in turn requires that the anonymous
browser be able to see the current flaws, and not try to edit flaws that
were fixed several edits ago.
On the other hand, for specifically requested, "opt-in" preferences for
less-dynamic site content, there's no reason a backup/failover site
couldn't be in operation and serving pages 24/7. In fact, that's far
better than the alternative (a backup/failover that does nothing but
suck snapshots and sit around waiting for orders). This would surely
appeal to some users, but not as many as the up-to-the-minute site,
because of likely decreased access latency. I could be wrong about
that: it might end up hammered with view-only traffic by people that
don't care to see the newer version unless they set out to edit. I
don't think I'm wrong, though.
--
Chad Perrin
[ CCD CopyWrite |
http://ccd.apotheon.org ]