Wiki Home

Wiki Web Service


Namespace: B2B
This topic covers how wiki servers communicate and what type of information they exchange.

In order to avoid each wiki server becoming an island of information accessible only within a single wiki server, Wikis must be able to communicate and exchange information.

This means by which wiki communicate is by exposing specific Web Services. These services are grouped in levels, where each level represents an increasing degree of integration as outline in the following topics:

Level 1 Interoperability
Level 2 Interoperability
Level 3 Interoperability

A wiki can chose to support any of these features, however, in order to support higher level features the lower level features should be supported.

It is important for a subscribing wiki to clearly indicate that a topic resides on another wiki server. This can be done in several ways, in the tooltip of the link, in the text of the anchor, in the color of the link, etc.
I hope I'm not jumping in too early here, this is very interesting. How does the (somewhat orthogonal) issue of a user's specific rights on a Wiki or wiki topic play in here? For example, I suppose TopicReplication is really just a TopicPublish with the published versions set as "read-only" to all users in the subscribing wikis... (Or have I misunderstood?) - ?lc
Good point! We need to hash through the rights issues, and how trusts between wikis, if any, will be handled...-- Steven Black
Topic replication is a method for distributing topics to other wikis and keeping the content in sync with the topics home. Topic publishing is the process of distributing topic lists to subscribing wikis to facilitate linking to those topics. ?jMM
I am so glad some great minds are engaging on this {s}. It seems that in order to maintain equitable user-rights between two wikis, some sort of agreement of user-types needs to be made between those wikis. This could be very simple: Wiki-wide Edit/No edit, Read/No Read, but could also get quite perverted like: Topic-specific rights (which are aimed at different user groups), Append only rights, then of course the right to set publish/subscribe settings for a topic etc. - ?lc
Access rights to wiki topics remain under the control of the wiki hosting the topic. In the case of level 1 or 2 interop the user navigates to the wiki hosting the topic to view or edit the topic. In the case of level three, the topic is cached on the subscribing wiki. ?jMM
So, with level three (replication) the publishing wiki is giving carte-blanche read rights to all users of the subscribing wiki. I assume editing is still handled by the owning wikiserver which gives an opportunity for validation. Seems like this validation could be facilitated seamlessly via a publish/subscribe system for users thus allowing the sufficiently endowed user to navigate between servers without re-authenticating. Although, I'm not sure how this would be implemented without cookie-sharing - ?lc
In level 3 it's possible for a wikiserver to publish different topics to different wikis and the subscribing wiki could then restrict access by user. There is nothing to stop two wikis from sharing user lists and access rights as well. However, this is essentially a specification public sharing of wiki topics with the goal of eliminating redundancy between wikis. Many of the senarios where this type of authentication is useful can be handled by hosting the namespaces within the same wikiserver. jMM
Contributors: jMM
Category Global Wiki
( Topic last updated: 2001.05.18 09:36:56 AM )