More About the Server

You may have moved quickly into the steam tunnels of federated wiki. A colleague did and wrote asking some detailed questions without much context as to how the server got to where it is. Here is the story.

I think of wiki-server as a page store with incremental update. Little more.

Well, I sure glossed over a lot of ground there. Let me start with a series of facts, not making excuses, but to provide insight into the code.

* The wiki-server was originally written in ruby, with Selenium tests, but this proved hard to install because of ruby version hell.

* The node version is an Express app, a swiss army knife of web servers, using async idioms everywhere, and written to pass the tests.

* The farm machinery in the node version doesn’t just carry a subdirectory name to the disk driver, it spawns a clone of itself in the same memory space.

The node version turned out to be much easier to install, mostly because node was young then and hadn’t evolved into version hell. We chose node as our preferred implementation.

(I still run the ruby version for a few sites.)

At the same time we embraced npm packages as our module architecture on the client side too. Much of year two was spent pushing these choices to completion.

* Both the client and server code bases have been the work of many hands.

* The server was done by one volunteer, not yet a professional programmer, with the help of his brother, a lisp hacker. (expect indirection)

* The argument processing has grown with no central definition even though it may seem to have one.

* Dynamically loaded plugins can interpret newly introduced parameters which can be set multiple ways.

* The server fits into the category of an application-server, but those are expected to be stateless. (Our server is really just a db with incremental update)

* Wiki scales over the top (via CORS HTTP), not underneath as is expected of an application server talking to a db

* We have accumulated logic to conform to expectations of hosting companies though that has mostly atrophied.

* We have accumulated logic to conform to multiple user-identity mechanisms, though that has been recently abstracted.

* We have accumulated logic to accommodate HTTP and HTTPS in a browser environment that sets them against each other.

You might be thinking that this codebase is a real mess. I think otherwise. It has responded well to everything we have asked of it. I am especially proud of how a server-side plugin integrates into this machinery.

Keep in mind that a plugin author needs no permission from anyone to create a plugin, write content in terms of that plugin, and suggest that other sites install that plugin so others can benefit from the writing.

I offer as an example adding RSS to wiki.

Allen Wirfs-Brock invited Dave Winer and myself to join him once exploring our similar sounding use of light-weight servers. It was fun to get to know Dave but it was clear that he wasn’t going to read anything I wrote unless I could ship it over RSS.

As an experiment I adopted a blogging style for some of my writing and added a plugin that publishes it in RSS. The plugin appears as a little counter on the top of a table of contents.

This is the client-side of the plugin doing its job of counting things and offering the RSS icon which can be added to readers. Here is the server-side code that supports the client by actually counting pages and supports the RSS protocol by assembling up payloads to their spec and shipping them out on demand.

Contrast the 18 lines of that code that constructs the payload with the sprawling document that defines it.

I don’t actually think Dave reads what I write by RSS or any other means. But I don’t regret the time I spent writing it. I pushed on some boundaries regarding what is expected of a plugin and found that they respond well to unanticipated change.

I’ve reused this server-side approach several more times and always found it productive. Especially note that this productivity comes with no coordination with the wiki project leadership other than my familiarity with the server-side environment from being part of that leadership too.