Posts filed under 'General'
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
So there’s this interview with Alan Kay, an old-school Apple guy and frequent denigrator of today’s computers. Jes was talking the other day about how Kay’s metaphor of contemporary apps being like the pyramids - brute-force stacks of blocks made possible only by large numbers of Egyptian slaves - was so depressing for an ambitious coder. What we need is not more pyramids, but cathedrals. But no one has discovered the arch yet.
When the architects of Everything2 attempted to productize their core code (along with some other stuff), they named their company Blockstackers Intergalactic. In the best case, programming feels pretty much just like that: stacking blocks, like a happy or at least distracted kid sitting on a shag rug in the middle of the family room. In the worst cases, it feels a little more like being a slave in Egypt. Big fucking blocks, those were.
So that was on my mind when I concluded my post yesterday. I think I’ve been slacking off on 0.2 milestones because what’s left to do - adding a feature to the admin pages, then adding another one, et cetera - feels very much like mindlessly putting one thing on top of another. Many of the distractions I’ve been employing lately have actually been themed around (hopefully) eliminating some of this kind of busywork. Funny enough, not long ago I linked to one of them - Ruby on Rails, a web framework that promises, and seems to deliver, dramatically faster development of database-backed web apps - as a joke about the other context of “on rails:” that of being bored and having nothing to do but mindlessly move forward. I am hoping that RoR promises the opposite, but there’s no time to waste exploring it now.
Must. Stack. Blocks.
February 17th, 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
Found this paper on something Drupal is preparing or possibly not preparing, called the Content Construction Kit. I don’t know enough about the technical underpinnings of Drupal to be able to say exactly what’s going on here, for example, but even just the beginning of the next page tells me that there is some useful thinking there for how to extend Cornucopt’s content model out to the next level.
See, it turns out to actually be pretty hard to deal with things like search. So far, searching CoCo has been limited to title searches, but once you do full text search, how do you give users and/or admins a manageable way to say what it’s appropriate to search and what isn’t? Another way of looking at search is from the perspective of application-wiki problems. How do you tell your in-page widget to do something to a given set of pages? And truthfully, even title search is complex - I’ve already special-cased Corny’s database to keep track of what’s a comment so that they don’t appear in title searches. It’s not as if I should have to tell the changes table what every pagetype is, and write special SQL code for them all. And search isn’t the only such problem - RSS feeds are starting to look similarly tough.
So I’m hoping something in this document is gonna save my ass. The hope is that I will end up with an easy way for admins and/or users to define new pagetypes without writing PHP, and in some way consistent with permissions and generally not naughty.
February 3rd, 2005
So I wrote full-text display of articles into the Cornucopt RSS feed after reading this… but before I read the comments. So now I’m wondering why wikis don’t implement a URL blacklisting approach. I’ve been planning to write such a thing for Corny for a while, to support the weblogging functionality, but now I think I might move it up in the schedule.
I’m also thinking about how else we can make effective use of RSS (yes, and Atom) in CoCo, in ways that are at least a little bit generalizable. Subscribing to a page is a no-brainer, but can we integrate page changes with page comments in a way that makes sense on the technical end - that is, a way that allows for arbitrary extensions to basic page-y stuff?
It might be time to stop thinking of feeds as a check-box add-on feature and consider what we’d do with them if they were our main way of delivering content - which they might soon be.
January 8th, 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
Work is proceeding apace on the new hierarchy-related pagetypes, as well as the new-ish pagetype architecture (that is, the total rewrite of the one aspect of Cornucopt that really makes it unique… er, actually, the second total rewrite of said aspect). It turns out that when you make a new pagetype architecture, it’s a really good idea to finish it. Also, we (the assembled… currently three of us noodling about on the test site) have been distracted by shiny brain-destroyers of the PHP phylum.
You want hints about the seekrit projekt, don’t you. Fine.
December 21st, 2004
Like every implementation of Cornucopt (or at least, so I imagine), the seekrit projekt (Codename: Sleeping Princess) will be a mix of actual, formal changes to Cornucopt (that is, pagetypes and libraries that will be part of the distribution) and custom code that remains specific to the project (that is, ugly-ass hacks). The information architecture of Codename:SP is pretty much done, although I’m sure we will make changes once we have a running prototype; what’s in question is which of those IA features are appropriate to be generalized into the CoCo codebase. And, as I alluded in the previous post, a lot of those features have to do with hierarchy.
Hierarchy in wikis takes a lot of forms. The most popular is probably simple categories, which aren’t technically hierarchic at all, but are more like plain old metadata or keywords - what the Flickr folks call tags. While the tags in Flickr and del.icio.us got folks excited about what’s being called folksonomies by some, and simply “aggregated wisdom” by others, the ur-Wiki’s categories arguably got there first. (Why the excitement now, then? A little interface goes a long way.)
Besides a soft user interface, wiki categories are a soft form of hierarchy, and sometimes it’s advantageous to have something harder. Some wikis have implemented what they call namespaces, a familiar-looking way of writing hierarchy right into the title of a page (that is, with slashes: “ParentPage/ChildPage”) and having it happen magically. I am not sure why this has always sort of turned me off; maybe because it seems important to handle hierarchy with a lot of transparency and consistency. Also because this kind of hierarchy is not really a change from flat wikilinking. Which is fine, unless you want to do something like auto-generated nav, or an auto site map, and have it provide any meaningful context to the user. Most wikis have nothing that resembles a site map, and hierarchy makes this feel more important. A dedicated wikismith can of course maintain something that at least looks like an exhaustive site map, on the front page or elsewhere… but, again with the doing it yourself versus software doing it for you.
Since the very early days of Cornucopt design, before I’d written any code and back when the whole project was both more and less like a wiki, I have wanted it to have buttons named “Create Down” and “Create Sideways.” The idea being that an individual hapless web-slave, charged with creating a corporate website or just a personal one with a mix of traditional and weblog/wiki flavors, could construct the kind of tabbed, menu’d page structure we see so often without having to work at it much, or at all. I think this is what simple hierarchy in Corny is going to look like. Ideally, I’d like to leave to the HTML and CSS templates the matter of how hierarchy is displayed. That way, the difference between a chaptered-and-paged documentation look and a top-of-page nav bar with dropdown menus could just be a matter of a few clicks.
The firmest hierarchical form of all wiki forms is the sub-wiki, in which wikis contain whole other wikis. These contained wikis may or may not make pages contained in other sub-wikis, or the master wiki, linkable, searchable, or even visible. You see this most often on so-called wiki farms, Blogspot-esque services that provide free or semi-free wikis. The surrounding stuff is non-wiki in these cases - you can’t nest isolated wikis within each other like Russian dolls. But mightn’t it be neat if you could? I don’t know what such functionality would be good for, but I can’t think of a reason to disallow it either. If we want the uses of Cornucopt to surprise us, and we do, we have to add this sort of capability.
However, for the moment, the thought of integrating sub-wikis into CoCo in a flexible, removable way - including constraining search to one sub-wiki unless the admin doesn’t want it constrained, constraining links similarly, maybe doing so on a sub-wiki by sub-wiki basis instead of a global preference, and on and on - makes me want to grow a long beard and wander around muttering “doom, doom, doom.” So I think it will remain a hack for now.
November 22nd, 2004
1) We now have in mind, and in the design process, the first major site that will be built on top of Cornucopt. Its needs are fairly specific, as the needs of most CoCo sites will be, so it will distort development in interesting ways.
2) Case in point: I’ll be developing hierarchy more fully for 0.2 instead of wikifying templates. (Work on the core pagetype architecture is complete for now, knock wood.)
November 20th, 2004
Previous Posts