Posts filed under 'Roadmap'
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.
April 18th, 2005
It’s official: Fictionsuit is now a Ruby on Rails project rather than a Cornucopt project. Sometime after we are satisfied with the footing of Fictionsuit, Cornucopt itself will become a Ruby on Rails project, likely with some subtle shifts in focus as the new language and framework afford.
We may actually get Fictionsuit into beta in April due to this.
March 20th, 2005
What’s to be done for 0.2, zoomed in a bit:
Better admin - about a third done, I’d say.
Refactored page object - we’ll include db schema and methods for children/hierarchy and permissions right there on Page by default, instead of relying on pagevars and pagetypes. Some other things might shift around as well. This is not started yet.
More permissions UI - If I get ambitious I might want to do something like, say, give the creator of a page the authority to delete comments (at least for some pagetypes). I’ll need that anyway for weblogs when we get around to those, and just generally need to think through how such pagetype features are going to interact with permissions. Help would be welcome on this and I’ll try to rustle some.
We’re behind schedule for Fictionsuit and I have spent too much time fretting about design issues. Need to start stacking the blocks again.
February 16th, 2005
Preliminary tests on comments are going quite well on the test site, ho ho ho, and I should have some more integrated means of letting people play with them there shortly after new years. 0.2 will likely have a little more development of the adminny stuff, particularly user pages, comment deletion and usergroups, and then we’ll call it a point release. 0.3 will be weblogs, maybe some other hierarchic thingies, and probably wikified templates now that I’ve seen how easy that ought to be.
This maps pretty well to the needs of Operation: Sleeping Princess, except for some even more abstractified hierarchy that cuts to the core of Corny and will likely not be making it back into the source tree. We’re aiming for a beta of Op:SP in April.
It’s been a great year for the writing of unnecessary software! Here’s to more perverse notions and utterly compromised hackery leading the way to a better world in 2005.
December 27th, 2004
No, for reals this time. A roadmap. A plan of attack, perhaps.
0.1 - Basic admin pages, shields up, small change (prevents change from showing in recent changes), SoftlinkPage
0.2 - Better pagetype implementation, permissions, wikified templates
0.3 - Better admin pages, PageCollection/hierarchy (inc. CommentPage), more RSS/atom
0.4 - Weblog pagetypes, tags/CategoryPage? (Are categories a pagetype? Dunno, I’ll have to play with it. Tags and categories will probably require the same tech as what I’ve been calling a “DynaBlog,” a page that lists out the ten most recent results of some kind of search.)
0.5 - Kept page policy, better small-change, better install, … other
Out further than that are user groups, stupid email tricks (like Jot’s magic appending to a page), and even stupider API tricks, as well as all of the possible freaky magic I alluded to in the last post. And hopefully along the way we will be making things generally less buggy, more secure, etc.
Timeframes for all this? Shut up.
October 29th, 2004
Because I’ve promised my November free time to another project, I’m going to see if I can’t get an 0.1 release of Cornucopt onto SourceForge by the 31st. That means enabling user bans and page locks (and maaaaybe IP bans but likely not), and killing that one login bug. Seems possibly doable over the weekend.
But what I’m really here to write about is something else. I’ve been thinking some more about this wikified-templates thing, and how it could lead to what you might call “third generation” wikihood.
I have, floating around in this humid little brain of mine, some thoughts as to how pagetypes are going to have to change in the near future. It turns out that, as lovely as the object-oriented model is for me to write, it’s a bit confining. A new pagetype can, as far as I know, only inherit the behaviors of one parent class in PHP 4. (Heh - you might call it a strict-father model.) So, for instance, if I wanted to add functionality to the basic Page class that added Flickr-esque tags, but I also wanted to have tags on SoftlinkPages, I would have to duplicate the tag code, unless I’m mistaken.
I’ve decided to regress, if that’s the word, to the “plug-in” model favored by packages like WordPress and Movable Type. Instead of subclassing all of the Page code and modifying or extending it, most pagetypes will just be a bunch of functions that get called when a page of the right type does its regular Page thing. This may be easier for many developers to understand.
It also opens another door: that of actually having the PHP code that makes a pagetype work… (deep breath) reside in the wiki.
Obviously, you will not want to give just anyone access to a wiki page that gets executed as PHP code. This action on my part will raise the stakes on hard security a great deal; if there’s some hole in my code that lets people fake admin access, or whatever other kind of access that has the permission to create and modify templates, then people could inject PHP code that wipes the database, destroys files on the host computer, infects the host computer with viruses, and just generally kills kittens. Yikes.
But, he said while wiping his brow, think of the upside. Imagine if extending a wiki’s functionality were as simple as clicking ‘create new page’ and selecting the ‘pagetype’ pagetype. That’s what JotSpot is after, although they are taking the (frankly much more sane) approach of a vaguely programmatic markup language. It may be that I eventually decide that I am smart enough to take that approach, or I may build some kind of extra frippery that makes editing pagetype scripts take longer, or restrains it otherwise. Or I may just give people enough rope to hang themselves; what do I care?
I really want to find a way to do this. This is HyperCard reborn, this is a revolution in waiting. I have no reason to expect that I will get there first or at all, but promise like that is the reason I write code.
I am sounding a little wild-eyed and need to be more clear about how this all follows logically from wikified templates, and about how pagetypes, pagevars and templates would fit together in this model. Watch this space.
October 27th, 2004
And wikified templates! JotSpot has inspired me to move Cornucopt’s HTML templates (the HTML files, with wacky stuff written into them, that take raw CoCo-generated data and make them into web pages, via a package called Smarty) inside of Cornucopt itself, such that mere users might be able to write their own. (And such that the templates get the advantages of wiki, like a version history, et cetera.) Combined with pagevars and a helping of what B.A. Baracus would call “jazz,” this could get us almost all the functionality of JotSpot’s forms and searches. Right now, Cornucopt’s templates live in separate files, in a little folder called ‘templates’ in the CoCo file tree. This is much handier for my current purposes than having to edit them in a browser, which is why this change isn’t scheduled for a while.
Will there be security headaches? Well, you have to really trust users to let them write arbitrary HTML. JavaScript is harmful to children and other living things. IFRAMEs are just as bad if not worse. Those are the easy ones; determining exactly what subset of HTML users really need to build applications will take some thinking. Also, the searching thing really is half the battle - I may need to implement XPath the way JotSpot does to allow people to select the pages they need to. Allowing people to create pages that create other pages could get hairy, essentially becoming a flooding attack. So I’ll have to design that carefully.
Just taking the templates into the wiki is not so difficult compared to the rest of the picture. I should really make a detailed roadmap. That was kind of a non sequitur. I want to be able to do a cartwheel.
October 15th, 2004
I’m just going to do a little recreational sketching of the next major things to go into Corny, because I’m thinking about it, because friends are starting to suggest that they really could use it, and… hey, even though programming little spaceships is more fun than programming text fields, that doesn’t mean that programming anything is more fun than dreaming up features. So let’s go!
Permissions. I have a few bones’ worth of the skeleton of this already. The challenge is how to do the UI. I have some decent ideas on that too, but: basically, the default Cornucopt install will let the user who creates a new page not just decide what type of page it is, but decide who can use it. If the pagetype says they can choose. And if they can create the pagetype in the first place. It is all both saner and more complicated than I am letting on. Sigh.
Usergroups. A big part of what will make permissions usable is the usergroup pagetype, one of the first built-in pagetypes that will really abuse the whole concept of “type of page” (and by no means the last). By default, Cornucopt will let anybody make a group of users, and add any users to groups they’ve made. It will not do anything asinine like let you send them all messages. Usergroups will be fairly simple to start, with no real messaging at all; they’re just a way to aggregate a bunch of names when you’re writing permissions.
Admin pages. You will need ways to change all this stuff even after you’ve done it. Not all of those ways should go right onto the edit page. I already wanted to have admin pages in 0.1, but I was thinking more of the sitewide admin stuff… you know, the stuff for… admins.
Because I am dumb, I am thinking about doing these before I do these. But what I really, really need is a coding partner. Please, people; I know PHP is the language of peasants and madmen, but think of the glittering prizes. Or the menus.
September 2nd, 2004
0.1 milestone things we want/need:
- Admin pages
- “shields up” functionality
- “small change” functionality
- verified installability out of CVS/no major bork-ups
Then we will maybe even get fancy and release a files package on sourceforge.
Oh yeah: and I would like to verify that softlinks work. They will be our first big-pimpin’ feature, the kind that lets people know we are not their father’s Oldsmobile.
July 8th, 2004
So, haven’t worked on the ol’ Wicker in a while. I have one bug standing in the way of opening it up for testing by a few friends; the bug has to do with the login system.
I need to fire up a Wiki pretty soon, for an actual project - we’re documenting a small Oregon town - and it’ll just break my heart to fire up one of those Wikis with fake-ass authentication or ugly, uncustomizable front pages. But push is gonna come to shove eventually.
I have a tendency to slow down like this on all my programming projects; not surprising, given that I really need to get something besides the Internet into my life. Anyone got ideas for getting fired up?
November 13th, 2003