Hey everybody. It's been a while. My daughter has been a pretty huge focus of my life for the last few months, so development here has been on hold. I've also been in a long-term tinker cycle to try and figure out where to take things from here. We're continually beating our head against some of the inherent limitations of the site, and I think I have a technological way forward, but it's going to be a pretty large change.
We've made some pretty large technological strides past where Perlmonks is at, the only remaining of the ecore-based sites. While we continue to be open-source, and will forever be, the focus of the code is going to move away from a "novel engine concept" to move more towards something that we can use to build a better site. A lot of the things that have discouraged me from adding in a lot of the features that I would want is that there isn't a particularly clean way to do this. Ecore hacking involves putting up with a pretty grungy marriage of the controller and view layers of a web-application, and modern web frameworks such as rails show that there's a better way.
E2 stores all of its code inside the database. This is crazy. In the old days, this came along-side "So crazy it just might work", but these days, we've steered basically to full-on crazy. We have to undergo piles of performance hacks, and what we get out of it is a huge security hole, and the ability for a small staff to tinker as they might need to. Hard development of major new features just isn't a supportable thing in that model. There isn't any structure for testing, code revisions, sane template systems or any of the other sane things that websites have been using for the last ten years or more.
What does this mean for E2?
Essentially, that more's going to change beneath the surface, before we can change things on the surface, but I have a way forward. We're going to port the site to Moose and Mason2. I've already got a working prototype locally, so once that appears to be good, we'll cut over. The first step of this is going to be to cut the site over to using Wheezy instead of Squeeze. It's a low-churn update that is going to give us the module support we need to continue the development of this effort.
I'm about to go on vacation for a couple of weeks to the English countryside, where I'm going to hunker down and get the port out. Seriously. I'll probably meet some of you crazy britnoders while I'm there. Once I come back, we'll do the wheezy transition straight away, and we can start demoing to the tech crew what the Mason2/Moose port looks like.
Mar 17: Spent all night playing with Mason. It's got some benefits on top of Template Toolkit, also it looks like E2's build in toolkit. I wired up a Mason adapter, but without having a real model setup, refactoring it is basically giving myself another mess to clean up a bit later. So I saved that work off, and am taking my second cut at seeing what $NODE as a Moose object would look like.
Mar 25
The first thought here was "Why not port this site to Rails?", and I think that's an interesting idea. Largely, rails has solved a lot of what E2 was trying to do, and I am slightly proficient in Rails. I've started to work on a proof of concept for what that would look like, but I abandoned it; truth be told I don't know enough about it to make the transition quickly, the problem set isn't as much interesting or innovative, as it is hammering our entire data model to fit into ActiveRecord. There's also the non-trivial problem of a language change. Even though I've largely broken up with Perl for Ruby for my day-to-day coding stuff, I don't think that it's the right choice for E2. I have a strong desire to mark progress while we're changing things, but we're so in the weeds with problems with the current codebase that I'm not sure it's possible.
I've looked at Catalyst and Poet, both of which are Perl-based MVC frameworks. Neither of them solve any sort of problem that we're having. We already use CGI.pm to shunt output, and the website is already scaffolded to handle that. We don't need modules that support say, request routing or anything like that.
This leaves us with what we have, which is something. I don't want to throw out stuff that works, but I'd like to adapt it in such a way that we can continue to work with it until we get something out of it that makes some kind of sense. The problem here is that we need to change the wheels on the car while it is running.