The Everything Engine is what this website is running on. It was coded by our very own nate and others during the late twentieth century. It's based on Perl, and standard Perl modules like CGI.pm for handling CGI requests and DBI for database abstraction. Like Perl itself once was exclusively, the engine is under the Artistic License, qualifying it as free software. Besides e2, the other current websites that use the engine are PerlMonks, JavaJunkies, and call's Kahani.org. I don't believe there are any others left, but at one time Animefu and the Everydevel website were also running on the Everything Engine.

Active development on the engine itself was abandoned sometime around 2001 by Blockstackers Intergalactic and the rest of nate's company. Scattered community coding continued until 2003, but didn't produce anything significant. The version that we are running is based on the code that nate had written up until 1999 or so, which is version 0.8. Further development happened for two more years, but our version of the engine doesn't have any of it. The last version to be released, still available from Sourceforge, was pre-1.0 revision 2, i.e. the engine never came out of beta. We have of course since hacked on top of it, and PerlMonks has hacked theirs even more. Kahani.org is actually running pre-1.0 and benefits from the two years of latter development that Blockstackers put into it.

The basic data structure in the Everything Engine is the "node". You may have heard that "everything is a node". What this means is that (almost) every bit of data represented within the Engine is a kind of node, and this means that all nodes have some basic information that they share, such as create time and title or name. Users are nodes, writeups are nodes, nodetypes are nodes, superdocs are nodes, writeup-containers are another kind of node internally referred to as "e2node", and so on. The Engine by itself when installed only provides the basic framework on which to create nodes, but provides no nodes by itself. In order to facilitate bootstrapping a website, nodeballs are used, which are packages that contain families of nodes and basic relationships between them in order to get the first bits of content into a site. There is a basic nodeball that has the core of what any Everything system should contain, users, a root user, containers (nodes that are used to render a page), htmlcode (nodes that contain bits of code), htmlpage (nodes to fine tune the rendering of a page), nodelets (you know these) and so forth. The totality of this base nodeball is called ecore, but since "Everything Engine" is a mouthful, you'll see that we keep referring to the whole engine by just this nodeball that comes with it. Technically, ecore is just a part of the Everything Engine, but an essential part of it.

Ecore's history, now with the hindsight of what the internet has become, is one full of sorrow. The idea was always to capitalise on ecore, with e2 as its foremost example of what could be done with the engine, to make it a successful commercial website like Slashdot. But when the dotcom's bubble burst was complete in 2001, it became clear that this commercialisation was never to be. The vagaries of fate decreed that Slashdot's slashcode should succeed but Everything2's ecore should fail. All of Blockstackers Intergalactic's employees were laid off, and thus began e2's since perpetual life as a zombie website, one that should have died off with the other dotcoms, but somehow still lives on, forever clawing its way out of the late twentieth century, along with Perlmonks, and for a while, with Animefu and Everydevel.

On the technical side of things, ecore is implemented as a series of Perl modules that inherit from a base Everything module. There is an HTML module that takes care of rendering webpages, a NodeBase module for handling the creation, maintenance and deletion of nodes, and our ecore has Experience and Room modules for handling XP and our parody of IRC of a chat system. Ecore also implements an extensive caching system which helps pages load a bit faster. It provides syntax for embedding Perl into HTML (thus failing to enforce the separation of code from content), as well as dynamically loading user-written code in the form of htmlcodes. Ecore is really the best that 1999 Perl-driven website management and creation could offer.

A remarkable thing about ecore is how small it is. Our running version, as of this noding, is a paltry 11,465 of not very dense lines of Perl code. For comparison, the source code of a modern CMS like, say, Drupal, is closer to 30,000. This isn't because ecore is a beacon of good Perl coding (although for the time, the coding style of ecore isn't terrible). It's just because ecore doesn't do all that much that a modern CMS would be expected to do. It says, "everything is a node", and whatever you want to do on top of that is up to you. Ecore is neither going to help you or impede you to do anything else with it. Because ecore is meant to be used for everything, it defines very little, supposedly letting content and meaning arise by itself, imposing very few rules. The extent to which this goal was or wasn't successful is not for me to judge.

So there you have it. As of this noding, our particular deployment of ecore is spread across three servers running MySQL and Apache with mod_perl. Apache and mod_perl are pretty much required for ecore, but since it uses DBI for its database handling, we could technically use any other relational database manager besides MySQL. Hope you enjoyed this brief tour through e2's guts.

Log in or register to write something here or to contact authors.