No subject


Thu Nov 19 15:02:24 UTC 2009


editors are collaborating (enhancing each other) and conflicting
(overwriting each other). If you split them up into different rooms
when they should be collaborating and reduce the conflicts, then you
will win alot.

Even in Germany, most edits do not show up immediately. They have some
person to check the commits. Now that would also mean that those edits
before they are commited do not need to go a single data center.

People interested in getting all the versions available would need to
be able to find them. But for stuff like that people would be prepared
to wait a bit longer to collect the data from many servers if needed.
You should be able to just pull the versions you want in the depth
that you want. That selection of versions and depth would be a large
optimization in its self.

So there are different ways to reduce the load on a single server and
create pockets of processing for different topics. The only really
important thing is that people who are working on the same topic are
working on the same server or have a path of communication.

To sum it up, if conflicts are the major problem in the wikipedia, the
major cost in terms of review and coordination, then you should
rethink the workflow to push the processing time back to the editor
causing the conflict.

Right now the revisions are stored in whole, but not in part. If you
only add in new information then the you need less storage. That would
be one big optimization for the wikipedia to transfer only the changes
across the net and not full revisions.

For course even a new section could be a conflict if the new text is
garbage or in need of editing. If you want to replace a single word or
a sentence then lets say would create a conflict branch in one of
external conference rooms that would be the host of the page until the
work is finished there. The main server would just have a pointer to
the workgroup and the load would be pushed away. That also means that
any local server would be able to process the data and host the branch
until it is pushed back to the main server.

OK, well I think this is enough for now. I do ask you to remain
serious, and we can have a serious discussion on the topic of
optimisation.

thanks,
mike



More information about the foundation-l mailing list