Looking Back at eThreads
Sunday, January 15, 2012, at 07:28AM
By Eric Richardson
From 1998 to 2006, my history as a programmer can be traced by one application: eThreads. Originally a forum package intended to be a database-backed replacement for HyperNews, I quickly started to work on turning the code into a more generic CMS platform.
Getting Started
When I first started on eThreads in early 1998, I was 15 years old and working at Gospel Films, a non-profit in Michigan. The organization hosted websites for a number of Christian ministries, and one of the tools offered to them was a threaded forum package called HyperNews (the website appears to no longer exist, but you can find an archive.org snapshot of HyperNews). The functionality of the package was fine, but it used flat files for storage and required us to force all HyperNews traffic onto just one of the two frontend web servers we were using.
Up until this point, my programming background had been limited mostly to some BASIC programs on the Commodore when I was younger, but I had gotten it in my head that I wanted to start getting into that side of the wild new world of web development.
Sometime in April of 1998, I sat down to write a HyperNews replacement that I called eThreads.
ethreadsI
The first iteration of code—which you can find in this github branch—is amazing in its simplicity. The first RCS checkin came on April 21, 1998.
You can see my BASIC background as clear as day in the routing at the top of a script like this snippet from view, where GOTO-like "syntax" numbers are used to route between different functions:
&get_vars;
&select_group;
&options;
# Now we browse...
&main_topics_list unless ($syntax);
&write_message if ($syntax == 10);
&get_post if ($syntax == 20);
&posts_by_sender if ($syntax == 30);
&signup_form if ($syntax eq"signup");
&signup if ($syntax == 50);
&login if ($syntax eq"login");
In all, eThreadsI got to 1590 lines of code before I realized that it was time to start over and put what I had learned in those first few months of work to use in creating a better foundation.
eThreadsII
At 11pm on July 13, 1998, I checked in the first revision for eThreadsII. The next few months saw a lot of firsts. As I noted in a 2002 look at what was then four years of eThreads history:
eThreadsII was a big transition. Work started in July of 1998. September 19 saw the advent of mysql support. The same day saw a switchover to strict, signaling a huge change in the cleanliness of code. On October 7 caching started. November 11 marked the first time searching actually worked.
The code got up to 4,390 lines this time. Once again, though, as I continued to learn, I again saw the need to start over and correct earlier design decisions.
eThreadsIII
eThreadsIII was the codebase where eThreads actually turned into a product that someone could download and use. eThreads 1.2.1 came out in August of 2000, and can still be found floating around free software archives. In fact, that's where I had to go looking for it: my archives somehow got lost in the last 11 1/2 years. Fossies.org came to my rescue.
This code, started in early 1999, was my first to be object-oriented. By the 1.2.1 release it had support for extensible content types, and shipped with forums, "news forums" (blogs) and calendars. Themes were stored in the database and could be updated per-forum. One installation could host multiple domains and keep track of which forums went where. "Glomlets"—basically plugins for the content "glomules"—could wrap functions to add additional functionality. URLs were hardcoded, but very little else was.
I wrote this on the eThreads site:
Why would I write an eThreads glomule (?) module instead of building a custom app?
When you build a glomule module for eThreads, you've instantly added the the carefully tuned eThreads architecture to your application. You now have the inherant ability to support multiple servers, fully customizable looks, and unlimited glomules (data sets) without having to touch a bit of that in your code. What might take 2000 lines of code on its own can be done with a much simpler 100 line glomule module.
Nifty.
That 1.2.1 release contains 4,825 lines of code, along with a healthy 2,805 lines of comments.
eTevolution
In November of 2001, I forked the eTevolution core. As I wrote back in 2002:
This core is the core to finally complete the transition to content engine. All forum code is broken out into the module, and the core simply contains generic routines for thread-based data display. Work on this has gone really well to date, and hopefully a prerelease should be coming in the next month.
I got as far as an eThreads 2.0 Alpha 2 in November of 2003, but that promised release never came.
That's not at all to say I didn't keep working—at last checkin on November 23, 2005 the code was up to 10,190 lines, broken out into 101 files.
The code had morphed into a framework for building applications. It ran on mod_perl and was smart about caching data across multiple runs. It had sophisticated URL routing, a home-grown template language with logic like loops and conditionals, XML definition files for content types and a crazy function switchboard that supported lazy-loading of registered objects and the ability to inject overwritten objects at any point in the tree.
Around the beginning of 2006 I got over my first few false starts with Ruby on Rails and quickly ended up deciding that it was easier to write an application on someone else's framework than it was to write both pieces of the stack. Development of eThreads was done.
Still, while I may have taken the point a little too far—templates basically defined their application, loading arbitrary content engines and content buckets—this era of eThreads really still resonates in the way that I think about code and about framing an application to be used in multiple contexts. I still this there are some fascinating ideas in there.
Just don't make me try to just back in and explain to you how it all works. After six years, some of those fascinating ideas just make my head hurt.