-
Notifications
You must be signed in to change notification settings - Fork 188
Federation Details
In the following sections we'll develop the notion of a federated wiki by anticipating its behavior. We'll write in the Given-When-Then style made popular by the Cucumber testing framework.
In addition to FolkMemory, the Darcs Theory of Patches can provide inspiration to organizing sets of patches. The federation of pages across wikis is an implementation of [distributed version control] ( http://en.wikipedia.org/wiki/Distributed_revision_control). One difference with this setup is the Internet location of page clones will be tracked. In the popular DVCS systems, git, mercurial, etc, the location of the server is irrelevant. Only the commit author is recorded.
Here we assume it is possible to test a dropped url to determine if it refers to a federated wiki site. Perhaps this can be done by inspecting the JSON. I've submitted issue [#52] (https://github.com/WardCunningham/Smallest-Federated-Wiki/issues/52) asking for the creation of this mechanism.
- given a page with a factory
- and browser open on another federated
- when I drag the browser location to the factory
- then the factory becomes a link (new item type) to that location
- and the link includes the title and favicon
And
- given a link to a federated wiki
- when I click the link
- then the linked json is retrieved and rendered (as with other internal links)
And
- given a link to an ordinary website
- when I click the link
- then the browser goes to that website (as with other external links)
Here we assume that a federated wiki server becomes aware of other servers through links or forks and that it will continually poll those servers for page names of interest.
- given that I have visited another federated wiki site
- and that site has a page with the same slug as a page of my own
- when I view my own page
- then I will be shown that another (sister) site have the same page
- and the showing will be clickable as an internal link
And
- given that I have visited another federated wiki site
- and that site has a page with the slug I reference in a page of my own
- and I do not have a page with the slug I reference
- when I click the link
- then the linked json is retrieved and rendered (as with other internal links)
Here we assume that the journal of a forked page is detailed enough to recognize where in the journal of the original the fork took place. (CouchDB numbers each entry in its SEQ to be sure this is possible.)
- given an original page that I have forked
- and the original page has changes
- when I view the forked page
- then I will be shown that the original (sister) page has changes
And
- given an original page that has been forked
- and both the original page and the forked page have changes
- when both pages are viewed at once
- then conflicting actions will be highlighted in the journal
And
- given a page with a story item sourced from another federated wiki
- and that item has been edited in the source version
- when the copied story item is viewed
- then the action that made the copy will be highlighted in the journal
Practical use may indicate more use cases. In particular, periodically updated datasets should flow through the federation with actions (such as computations) reapplied where appropriate.
- given a place I own with a page I own
- when I edit the page
- then the page should update in place
- and the page's journal should reflect the action
- given a place I own
- when I edit a page I don't own (need to describe you you would be in this situation)
- then the page should fork and the fork updated in the place I own
- and the forked page's journal should reflect the fork
- and the forked page's journal should reflect the action
- given a place I own with a page I own
- and access to a copy of the page I don't own (need to describe you you would be in this situation)
- when I edit the copy I don't own
- then the forked and updated copy replaces my own page (can we do better?)