It’s a mad, mad, mad, mad content management framework
April 18th, 2005
So, this blog will be going into deep-freeze for a while (and I’ll regrettably have to close all comments shortly, because I don’t want to deal with the spam; email if you want to chat about what you find here). While I launch Fictionsuit, Cornucopt is going to take some time off to have an identity crisis. See, back when I first thought of the name Cornucopt, I actually envisioned it as an easier-to-install Ecore. With some push-button setup options for common social-software patterns, and in PHP. That’s about it. Oddly, as I retrace the development of Wicker, now rechristened Cornucopt, it has gotten closer and closer to Ecore. Let me give you a hazy sketch of what I think Cornucopt might look like if I get around to it after Fictionsuit, here in the post-Ruby on Rails world, where there are monorails through wide, green public parks with nary a trace of litter or cramped tennis courts.
Like Ecore, we start on the barest of wiki foundations. You have a bunch of things called nodes, or pages, or whatever, and you can add text and link them easily. Drupal does something like this, only you start with a front page and stuff like threaded comments enabled, for a more slash-cloney shape. Cornucopt’s starting structure will likely be similar to Drupal’s, only with non-threaded comments (or perhaps differently threaded) and tags enabled by default.
The interesting stuff about Ecore (or Drupal) lies in what you do from there, and how you do it. Ecore provides not only a framework for building out a site’s content, but for doing your customization and programming within the Ecore environment itself. You can define a node with a nodetype of “nodetype,” and then just start writing code into a textarea that defines what nodes of your new nodetype will do, and how they will display. You’ve got certain objects you can read or manipulate - a user object, a session object, the page’s text, and suchlike - and you just code up what you want. In theory, I think you have access to all of Perl.
So, even before I was all making out with Ruby on Rails, I was starting to think that Corny’s scheme of pagetypes was kind of a half-measure. I mean, if you want to make something new, you’ve got to write a bunch of PHP into a file, set all your permissions and stuff in there, throw the file up into a poorly named and placed directory (I was gonna get around to fixing that, honest), and then start using it and hope it works. I guess the last step is more or less immutable. But having tried to build things in Ecore, I could see that there was a better way, even though Ecore was pretty much the better way gone wrong. I wanted more things built for me, and more things that could hook together interestingly, and more things that were open to the rest of the net. Ecore doesn’t have a closed culture, exactly… but it has the Perl culture in spades. “There’s more than one way to do it, so we can’t possibly presume to do anything for you. Here’s a textarea. Good luck!”
The real reasons I decided to abandon Ecore were not the above, though. They were my unfamiliarity with Perl and the difficulty (impossibility, actually) of installing Ecore on shared hosting. Ironically, Rails isn’t very friendly with most hosting companies either. But this choice reflects my new, corrected-for-reality notion of who’s going to use Cornucopt and how. I’ve decided to commit to the fact that someone who really wants to customize a wiki is going to write code of some kind. I think they’ll find Ruby code friendlier to write than Perl code. I think Corny’s built-in options will go a decent-enough way to fulfilling other, less extensive needs that I don’t feel as bad about requiring code for the serious kung fu. And I think that Rails is hot enough that Rails hosting will spread fast.
Plenty of design hurdles remain, however. Funny enough, security of executable code isn’t a big worry; Ruby has some sandboxing built in, so I’m not really concerned about restricting them to selected objects and methods. Figuring out what methods people will need, though, might get interesting. Also, these built-in things I’m waving my hands about - what will they be, precisely? How will they be architected, and how the hell do I think I’m gonna make them all snap-together easy? And is it wise to build an application framework on top of another application framework like this?
All of these are questions I’ll have on the back burner until this fall at the earliest. First I’ve got to launch Fictionsuit, then build features I have foolishly already planned for “soon after launch,” then whatever comes after that. Then I need to see if a big generalizing machine to enable other people’s creativity is still something I want to build at all.
If not… well, all this work has been fun. I’ve learned a lot, including the ability to let go of projects without all that guilt. :-) But mostly I’ve learned about my work habits and ability to take a large project to fruition (or something like it) without having it just loom over me, ignored, like a heartbroken pet zombie. Much.
Entry Filed under: General, Meta, Vision, Implementation, Roadmap