Difference between revisions of "Extension talk:P2P.php"

From Organic Design wiki
(Remote Locations)
(Synchronisation)
 
(3 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
=== Synchronisation ===
 
=== 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.
 
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.
 +
 +
This merging of a collection of revisions process is the central functionality needing to be defined for the P2P wiki concept. However, it the process is also directly applicable to the idea of unifying multiple instances of the same content across many collaborative environments. People can collaborate on the article from any of the environments it exists in.
  
 
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.
 +
*[[Git]] could be used as the P2P revision synchronisation layer
  
 
== Remote Locations ==
 
== Remote Locations ==
Line 14: Line 17:
  
 
== See also ==
 
== See also ==
 +
*[[Git]] ''- could be used as the P2P revision synchronisation layer''
 +
*[[Edit conflict]]
 
*[[PeerPedia]]
 
*[[PeerPedia]]
 
*[[Extension talk:SQLite.php]]
 
*[[Extension talk:SQLite.php]]
 
*[[Extension talk:Daemoniser.php]]
 
*[[Extension talk:Daemoniser.php]]

Latest revision as of 10:57, 23 July 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.

This merging of a collection of revisions process is the central functionality needing to be defined for the P2P wiki concept. However, it the process is also directly applicable to the idea of unifying multiple instances of the same content across many collaborative environments. People can collaborate on the article from any of the environments it exists in.

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.

  • Git could be used as the P2P revision synchronisation layer

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