Issues: * Access - same content (wikis) available from different locations (servers). * Connections - see UnifiedRecentChanges (previously InterWiki) ; linking related content (wikis) * Directing - ''connections'' to the right ''access'' points - a little like a geographic traffic load balancer (there's that open one related to iptables, by VA Linux/sourceforge if I remember correctly). //mawi (more below) Random thoughts: Can the wiki be generalized to support separate installations in different locations, sharing the same repository, with possible redundancy and some kind of replication? Can the wiki model be used for producing text in Smalltalk instead of English? :) PavelPerikov. Surely this should be possible. There are some newer attempts at distributed wikis, but they seem to be complete mirrors, which is only one model. A distributed wiki should run across multiple servers, and should be capable of supporting a more robust database as a result. It would be more robust against network failures, and also against server failures. There would possibly be some problems with updates, and some see that as being very significant, though in practice it might only present a small difficulty, as updates could be handled by special processes. One distributed model is that each server will provide a mirror of the wiki, but others might allow for different wiki entries to be handled by different servers. Searching for keywords and locating articles may be a significant overhead in a large wiki, and improvements could be obtained by distributing articles over a number of servers. ''In the spirit of OnceAndOnlyOnce, the search for keywords can be done by the server and the list of articles also maintained in a simple flat text TitlesIndex and WordsIndex, accessible as a HyperLink by any browser. The list could be run once a day, week or month depending on Administration's desires. Requiring the server to perform a real-time search could be provided on a FeeBasis, if the interval of Daily, Weekly or Monthly were not sufficient.'' -- DonaldNoyes Delays due to geographical location could be minimised by using multiple distributed servers, and this would have a beneficial effect on the total network traffic. It has been argued that this type of software will be complex, and difficult to manage, but I suspect that once someone has actually implemented such a system, that these objections will diminish rapidly. Another fairly obvious advantage is the possibility that such a wiki could be very large, and may not require a single individual or organisation to pay for the hardware/software infrastructure. Some would worry about the lack of centralised control, however. DavidMartland ---- For connecting wikis there is InterWiki. Is there any replicating Wiki software? (Synonyms: Just use "wikis" to mean one server/node/etc. KISS.) //mawi ---- There's some discussion of a distributed wiki at http://wikifeatures.wiki.taoriver.net/moin.cgi/FailSafeWiki . But as far as I know, WikiPedia is the only wiki that has ''any'' distributed features. More recently, OddMuse has added some page-synchronization abilities: http://oddmuse.org/cgi-bin/wiki/Page_Syncronization . ---- '''I''''''nfoTopics in a Distributable format''' Perhaps one might build topical or categorical wiki spaces which would be "distributable" and to keep it simple the distributable module would be the named using the topic name and the topic date of distribution: * ExtremeProgramming_20060527 A third identifying classification might be added to identify a single home or place of origin, as in: * ExtremeProgramming_WardsWiki_20050627. The first form would be the generalized topic which might be from many sources, while the second form would be the specialized, single source topic space. The distribution, to be efficient would be via a compressed file containing all of the pages in the topic, along with supporting system files such as PageList, WordList, ChangesIndex (Similar to RecentChanges, but consisting of the page name, the last date changed, and who modified it on that date), as well as other LinkPages which tie the topic to a centralized server which contains the list and location of all distributable modules in "T''''''heCollection". The several collections would be assembled and made viewable using a local PersonalWiki Engine. -- DonaldNoyes ---- DavidCary wants to build a "fault-tolerant" wiki. In his eyes, the "lack of centralized control" is a *good* thing. I think the only way to make a wiki fault-tolerant to distribute at least 2 copies of each wiki page over at least 2 separate wiki servers. So no matter what happens to one server, people can still read and write those wiki pages ( at the other server(s) ). http://communitywiki.org/odd/SoftwareBazaar/distributed_wiki ------ I have one question: why? What would distributing get you that centralization couldn't? Centralization is generally easier to create and manage software and tools for. Wiki text is not at all bandwidth-intensive compared to say a painting repository. ''There are several reasons I can think of: demotion of central authority (reduces risk of tyranny by elite), reliability through redundancy, etc. Bandwidth might matter a lot more than you might think depending on the class of Wiki involved (some have quite a few images... but with enough bandwidth, there could be videos and interactive objects with a SmartWiki). That said, I'm not particularly interested in this idea unless it gets two major enhancements: (1) offline operation - as per distributed version control mechanisms, such that I can read and write pages even on my laptop when it's offline then automatically push my changes (with some support for handling conflicts) to the more 'official' server(s), (2) RuntimeUpgradeableCore, such that the lack of centralization doesn't become a trap that prevents global updates to the service.'' A more concrete version of the "offline operation" reason: Imagine a wiki located inside a company's network and not generally accessible from outside. When working from a branch office, the central wiki location might only be accessible when a VPN connection is up and running. When the central wiki location is unavailable, a branch office might still want to be able to access (and modify) the pages on the wiki. ----- This is a solved problem. Use a VCS-backed wiki (such as ikiwiki, http://ikiwiki.info/) with a DVCS (such as git). ikiwiki explicitly discusses this sort of thing in a few places: http://ikiwiki.info/tips/distributed_wikis/ http://ikiwiki.info/tips/laptop_wiki_with_git/ http://ikiwiki.info/tips/laptop_wiki_with_git_extended/ Or use a DVCS with a built-in wiki (such as Fossil, http://www.fossil-scm.org/index.html/doc/tip/www/wikitheory.wiki). ---- See WikiWebTransferProtocol WorldWideWikiWeb MultiServerWiki PullPushWiki needs checksum check with other mirrors, server rating, merging, can be done. ---- CategoryWiki