Bloomer Local Fed Server

From Bloomer

Description    (1)

We examine a revised local architecture that includes an instance of the Federation Server    (1A)

Image    (2)

Discussion    (3)

Evolving MediaWiki extensions to perform complex tasks such as maintaining a local topic map could be problematic; a goal of this revised architecture is to accomplish that task as expeditiously as possible. While it may yet prove desirable to create a PHP application that runs as an extension to MediaWiki to provide topic maps services, we are here exploring the notion of simply embedding a copy of the TopicSpaces federation server locally.    (3A)

This means that all local activities such as topic creation, IBIS conversations, tagging, and others can be maintained locally. The philosophical stance behind doing things locally is this: each portal represents the work product of a particular tribe. That work product should be maintained separately from others. Federating all portals is the task of the Federation Server on the right side of the image, while federation of local work products is the task of the individual instance of a Federation Server embedded with MediaWiki.    (3B)

Local federation servers communicate, over the web, with a global Federation Server through a private channel of their own. Instances of MediaWiki then view the global federation through the Explore tab.    (3C)

MediaWiki communicates with the local federation server through AJAX web services calls.    (3D)

Precisely how this will be implemented remains to be determined. However, the vision is this:    (3E)

In a traditional MediaWiki activity, a new page is created either by user intervention or under the direction of some PHP code.    (3F)

In an envisioned scenario, forms are used to create new content.    (3G)

Those forms send their content to the federation server.    (3H)

The federation server returns a response to MediaWiki, say, to the extension that made the AJAX call, from which new content is added to MediaWiki.    (3I)