Bayle Shanks. "WikiGateway - A Library for Interoperability and Accelerated Wiki Development."

Proceedings are available on wikisym.org and through the ACM digital library.

This paper introduces WikiGateway.

The paper and also preliminary talk slides have been uploaded/attached to this page (see the files box on the right).

The accompanying talk is the second out of 3 presentation in the Monday 1:30pm - 3pm session.

What is WikiGateway?

WikiGateway is an open-source suite of tools that allows you to write programs that read from and write to remote wiki servers. WikiGateway provides a unified interface to different types of wiki engines. Your programs can access the remote wiki server using any of these modalities:

• Command-line client
• Python module
• Perl module
• WikiRPCInterface protocol
• Atom protocol
• WebDAV protocol

The type of wiki server on the other end must be supported. WikiGateway currently supports these wiki engines:

• OddMuse
• UseMod
• MoinMoin
• MediaWiki
• Or any WikiRPCInterface-supporting server

Due to its modular design, it is relatively simple to extend WikiGateway to support other types of wiki engines. All you need to do is to write a short Python "driver" that tells WikiGateway how to talk to the new wiki engine.

In addition to its other functions, WikiGateway allows you to add DAV, Atom, or XMLRPC capabilities to any sup- ported wiki server. Using it this way does not require you to write any code. Note that this allows wikis to interoperate with other standards-compliant tools, such as tools that mount DAV resources as a filesystem.

Developers can use WikiGateway to hide the differences between wiki engines and build client-side applications which interoperate with many different wiki engines. WikiGateway aims to serve as the foundation of client-side tools for wiki users.

Demo applications include a wiki copy command, a spam- cleaning bot, and a tool to recursively upload text files inside a directory structure as wiki pages.

In the future, other applications could include a wiki client, a WikiRefactoringBrowser, wiki page interchange between different types of wiki engines, an offline wiki editer, and more.

Formatting notes

The .ps version of the paper has a problem with link formatting.

The .txt version is in EasyLatex format.

---

Seb's transcript (please edit):

BShanks - WikiGateway

This talk is mainly targeted to developers who want to write programs that communicate to wikis.

Here's the (command-line) operation of writing to a wiki page. Here's how you would read a wiki page. You can also get the recent changes. You can get a list of al pages, and past versions of pages.

You have to tell the type of the wiki that you're interacting with. Here's a method similar to the command-line example.

You can also use WikiGateway as a proxy server. Let's say UseMod doesn't know WebDAV. What you can do is to use the WebDAV proxy server in WikiGateway in between the client and the wiki server. What it does is actually translate calls to the usual HTTP calls.

This lets you interoperate with other standards-compliant tools. Supported protocols: Atom, WebDAV, WikiRPCInterface.

Supported WikiEngines: OddMuse, UseMod, MoinMoin, MediaWiki, PhpWiki or any WikiRPCInterface-supporting server.

To extend WikiGateway, you write a "driver" (actually a Python class) for your favorite WikiEngine. Example: OddMuse.py is 192 lines.

Part II is why this is exciting. First, developers are already spending time implementing interfaces to wiki engines: WikiRPCInterface, WWW::Wikipedia… Why not collect all these under a single API?

You want interoperability without anyone having to do anything. There isn't really consensus on which protocol to use. WikiGateway lets us start working without needing to settle on one protocol first. See also Jalkanen, DavWiki, Wikimania.

Wiki page interchange. Wouldn't it be great to copy pages from one wiki to another? Yes. You need two things. 1) be able to get source on one wiki and be able to put source on another wiki. 2) be able to translate between wiki markups.

One thing this would enable is freedom for users to choose their wiki software. Let's say I want to read MeatBall using the MoinMoin interface. Put WikiGateway in between the MoinMoin frontend and Meatball.

Last thing is writing clientside tools. E.g. a rich client-side wiki editor. We have a chicken-egg dilemma: servers don't provide an API because there aren't any clients, and there are no clients because few servers provide APIs.

I think a lot of the features that people want to add should be added on the client side.

WikiGateway will help wiki softare develop faster. Today, you have to convince 50 development teams that your feature is a good idea, then implement the feature for 50 different wiki servers, then convince 500 wiki admins to upgrade their software. With WikiGateway-based client-side tools, you just implement the feature once, don't have to bother the others, and the users can get it if they want.

We currently have a lot of fragmentation of developer effort. The aggregate effort of developers is divided by the large number of wiki engines. Whenever possible, we should write client-side tools that are compatible with many wiki engines. So you only have to implement a feature once.

There are a few problems you can imagine with WikiGateway. First, is security. This could make it really easy to write editwar bots or wipeout scripts. I do think this will be a problem. However, people will do it anyway but maybe a year or two earlier. I think the benefit outweighs the risk. Second, if each user has a different way of interacting with the wiki it could lose some of the common context that people have now.

There are applications that already use WikiGateway: wikicp, spamclean.py, and a tool to recursively upload text files inside a directory structure as wiki pages.

Future applications include: A wiki client, a WikiRefactoringBrowser, wiki page interchange, offline wiki editor, UnifiedRecentChanges, global search and replace, etc.

In summary, today, if you want to access OddMuse, OddMuse, … you can now do so using the command line, perl, python, ...

Thanks to LesOrchard, …