Difference between revisions of "Extension talk:P2P.php"
(→Synchronisation: conflicts) |
(Remote Locations) |
||
Line 9: | Line 9: | ||
To start with a sync can just consist of the ordering by time of all sources revisions and merge them if no overlap each time. On cases where there is overlap, the revision merge must first revert to the revision it's based on and then (with a conflict message in summary) and then implement its revision change. Such events should be added to the talk of both contributors involved. | To start with a sync can just consist of the ordering by time of all sources revisions and merge them if no overlap each time. On cases where there is overlap, the revision merge must first revert to the revision it's based on and then (with a conflict message in summary) and then implement its revision change. Such events should be added to the talk of both contributors involved. | ||
+ | |||
+ | == Remote Locations == | ||
+ | After synchronisation is handled, it's only a small addition to the code to allow the ability to package up the revisions in MediaWiki's own XML export format so that the changes can be propagated as files rather than directly over HTTP. This would mean that synchronisation can be maintained "in the field" even in circumstances where the field units don't have access to internet at all such as remote villages. | ||
== See also == | == See also == |
Revision as of 01:31, 23 January 2008
Concept
To develop the PeerPedia solution using a standard MediaWiki code base running on every peer. The peer-based MediaWiki doesn't need to be highly scalable and so doesn't require a powerful database server like MySQL or PostgreSQL and doesn't require a standalone web-server like Apache either. MediaWikiLite extension is being developed to replace the database server with the SQLite PHP library and to allow the MediaWiki PHP code to run as a daemon which communicates directly with its clients over an HTTP socket instead of running as a module or CGI of a web server.
DHT
This extension is used in conjunction with the MediaWikiLite extension to allow a P2P layer directly connect clients who are editing the same articles so that they can synchronise data, reduce edit-conflicts and act as redundant caches for the data they share. Eventually the P2P layer should incorporate a DHT to maintain indexes of active peers and the article content they hold.
Synchronisation
The P2P layer also allows users to work offline and have their changes synchronise when internet bandwidth becomes available. In these cases, edit conflicts would need to be handled using the workflow system since there could be many revisions by the time synchronisation occurs.
To start with a sync can just consist of the ordering by time of all sources revisions and merge them if no overlap each time. On cases where there is overlap, the revision merge must first revert to the revision it's based on and then (with a conflict message in summary) and then implement its revision change. Such events should be added to the talk of both contributors involved.
Remote Locations
After synchronisation is handled, it's only a small addition to the code to allow the ability to package up the revisions in MediaWiki's own XML export format so that the changes can be propagated as files rather than directly over HTTP. This would mean that synchronisation can be maintained "in the field" even in circumstances where the field units don't have access to internet at all such as remote villages.